php / php/php-src

Microseconds to error log

オープン
#9,745 コメント 3 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Feature Status: Needs Triage
主要言語
C
スター
40.4k
フォーク
8.2k
平均マージ
2日 13時間
マージ済み PR(30日)
96

説明

Description

Hi there,

Not sure if this is the right place to discuss the topic. Please, guide me to the proper place if this needs to be re-directed.

We have quite a high-loaded environment and we really want to see timestamps containing microseconds in our logs. It is easy to do for our custom logger but error messages from the PHP itself narrowed down to seconds (I'm talking about method php_log_err_with_severity()

In our repository, we have a hacky patch that adds microsecs in this log as well. Unfortunately, such a solution is not really a good approach to looking into the future.

I wanted to adopt our patch to share it with the community and potentially merge it into upstream but stumbled upon the fact that it isn't really straightforward to format a date with microseconds using the standard API available for an extension.

Basically, I found a couple of options:

  1. We can instantiate a DateTime object and call DateTime::format(). It looks working but it makes the logging function way more complicated and potentially heavy

  2. date_format works directly with timelib_time and can properly handle microsecs but it is hidden inside ext/date/php_date.c, Not really sure if it's a good idea to make it public

  3. In theory, it is possible to add one more parameter to php_format_date but it'll break all the existing code. The change of signature doesn't look like a good option. However, we might be able to introduce another function if we want to encapsulate work with timelib_time within the ext/date.

Looking into the future, probably we would like to have this format configurable, if so it looks easy to do but still I can't see an easy way to handle the microseconds issue.

Could you please help me to find the right way and share your thoughts about this topic (maybe there are strong objections against such a change)?

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず main/main.c の php_log_err_with_severity() と ext/date/php_date.c の日付フォーマット処理を読んでください。Issue に記載されている利用可能なアプローチを比較し、既存の呼び出し元を壊さずに受け入れられる upstream API または設計を判断してください。マイクロ秒単位のエラーログのタイムスタンプについて、スコープと実装方針に合意し、実行可能な状態になれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
c, php
領域
backend
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。