1 | <?php |
||
23 | class SentryLogWriter extends \Zend_Log_Writer_Abstract |
||
24 | { |
||
25 | |||
26 | /** |
||
27 | * Stipulates what gets shown in the Sentry UI, should some metric not be |
||
28 | * available for any reason. |
||
29 | * |
||
30 | * @const string |
||
31 | */ |
||
32 | const SLW_NOOP = 'Unavailable'; |
||
33 | |||
34 | /** |
||
35 | * For flexibility, the factory should be the usual entry point into this class, |
||
36 | * but there's no reason the constructor can't be called directly if for example, only |
||
37 | * local errror-reporting is required. |
||
38 | * |
||
39 | * @param array $config |
||
40 | * @return SentryLogWriter |
||
41 | */ |
||
42 | public static function factory($config = []) |
||
74 | |||
75 | public function getClient() |
||
79 | |||
80 | /** |
||
81 | * Returns a default set of additional data specific to the user's part in |
||
82 | * the request. |
||
83 | * |
||
84 | * @param Member $member |
||
85 | * @return array |
||
86 | */ |
||
87 | public function defaultUserData(\Member $member = null) |
||
95 | |||
96 | /** |
||
97 | * Returns a default set of additional tags we wish to send to Sentry. |
||
98 | * By default, Sentry reports on several mertrics, and we're already sending |
||
99 | * {@link Member} data. But there are additional data that would be useful |
||
100 | * for debugging via the Sentry UI. |
||
101 | * |
||
102 | * N.b. Tags can be used to group messages within the Sentry UI itself, so you |
||
103 | * only want "static" data, not somethng that can drastically or minutely change, |
||
104 | * such as memory usage for example. |
||
105 | * |
||
106 | * @return array |
||
107 | */ |
||
108 | public function defaultTags() |
||
117 | |||
118 | /** |
||
119 | * Returns a default set of extra data to show upon selecting a message for analysis |
||
120 | * in the Sentry UI. |
||
121 | * |
||
122 | * @return array |
||
123 | */ |
||
124 | public function defaultExtra() |
||
130 | |||
131 | /** |
||
132 | * _write() forms the entry point into the physical sending of the error. The |
||
133 | * sending itself is done by the current client's `send()` method. |
||
134 | * |
||
135 | * @param array $event An array of data that is created in, and arrives here via {@link SS_Log::log()} and {@link Zend_Log::log}. |
||
136 | * via {@link SS_Log::log()} and {@link Zend_Log::log}. |
||
137 | * @return void |
||
138 | */ |
||
139 | protected function _write($event) |
||
151 | |||
152 | /** |
||
153 | * Return the version of $pkg taken from composer.lock. |
||
154 | * |
||
155 | * @param string $pkg e.g. "silverstripe/framework" |
||
156 | * @return string |
||
157 | */ |
||
158 | public function getPackageInfo($pkg) |
||
176 | |||
177 | /** |
||
178 | * Return the IP address of the relevant request. |
||
179 | * |
||
180 | * @return string |
||
181 | */ |
||
182 | public function getIP() |
||
191 | |||
192 | /** |
||
193 | * What sort of request is this? (A harder question to answer than you might |
||
194 | * think: http://stackoverflow.com/questions/6275363/what-is-the-correct-terminology-for-a-non-ajax-request) |
||
195 | * |
||
196 | * @return string |
||
197 | */ |
||
198 | public function getRequestType() |
||
205 | |||
206 | /** |
||
207 | * Return peak memory usage. |
||
208 | * |
||
209 | * @return float |
||
210 | */ |
||
211 | public function getPeakMemory() |
||
217 | |||
218 | /** |
||
219 | * Basic User-Agent check and return. |
||
220 | * |
||
221 | * @return string |
||
222 | */ |
||
223 | public function getUserAgent() |
||
231 | |||
232 | /** |
||
233 | * Basic reuqest method check and return. |
||
234 | * |
||
235 | * @return string |
||
236 | */ |
||
237 | public function getReqMethod() |
||
245 | |||
246 | /** |
||
247 | * @return string |
||
248 | */ |
||
249 | public function getSAPI() |
||
253 | |||
254 | } |
||
255 |
The PSR-1: Basic Coding Standard recommends that a file should either introduce new symbols, that is classes, functions, constants or similar, or have side effects. Side effects are anything that executes logic, like for example printing output, changing ini settings or writing to a file.
The idea behind this recommendation is that merely auto-loading a class should not change the state of an application. It also promotes a cleaner style of programming and makes your code less prone to errors, because the logic is not spread out all over the place.
To learn more about the PSR-1, please see the PHP-FIG site on the PSR-1.