You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

96 lines
3.2 KiB

#include <ccan/array_size/array_size.h>
plugin: Add new notification type: warning This notification bases on `LOG_BROKEN` and `LOG_UNUSUAL` level log. --Introduction A notification for topic `warning` is sent every time a new `BROKEN`/ `UNUSUAL` level(in plugins, we use `error`/`warn`) log generated, which means an unusual/borken thing happens, such as channel failed, message resolving failed... ```json { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;d better check it; `error` means something extremely bad is out of control, and it may lead to crash; 2. `time` is the second since epoch; 3. `source`, in fact, is the `prefix` of the log_entry. It means where the event happened, it may have the following forms: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `plugin-manager`; 4. `log` is the context of the original log entry. --Note: 1. The main code uses `UNUSUAL`/`BROKEN`, and plugin module uses `warn` /`error`, considering the consistency with plugin, warning choose `warn` /`error`. But users who use c-lightning with plugins may want to `getlog` with specified level when receive warning. It&#39;s the duty for plugin dev to turn `warn`/`error` into `UNUSUAL`/`BROKEN` and present it to the users, or pass it directly to `getlog`; 2. About time, `json_log()` in `log` module uses the Relative Time, from the time when `log_book` inited to the time when this event happend. But I consider the `UNUSUAL`/`BROKEN` event is rare, and it is very likely to happen after running for a long time, so for users, they will pay more attention to Absolute Time. -- Related Change 1. Remove the definitions of `log`, `log_book`, `log_entry` from `log.c` to `log.h`, then they can be used in warning declaration and definition. 2. Remove `void json_add_time(struct json_stream *result, const char *fieldname, struct timespec ts)` from `log.c` to `json.c`, and add related declaration in `json.h`. Now the notification function in `notification.c` can call it. 2. Add a pointer to `struct lightningd` in `struct log_book`. This may affect the independence of the `log` module, but storing a pointer to `ld` is more direct;
6 years ago
#include <lightningd/json.h>
#include <lightningd/notification.h>
const char *notification_topics[] = {
"connect",
"disconnect",
"warning",
"invoice_payment",
"channel_opened"
};
bool notifications_have_topic(const char *topic)
{
for (size_t i=0; i<ARRAY_SIZE(notification_topics); i++)
if (streq(topic, notification_topics[i]))
return true;
return false;
}
void notify_connect(struct lightningd *ld, struct node_id *nodeid,
struct wireaddr_internal *addr)
{
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "connect");
json_add_node_id(n->stream, "id", nodeid);
json_add_address_internal(n->stream, "address", addr);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
void notify_disconnect(struct lightningd *ld, struct node_id *nodeid)
{
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "disconnect");
json_add_node_id(n->stream, "id", nodeid);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
plugin: Add new notification type: warning This notification bases on `LOG_BROKEN` and `LOG_UNUSUAL` level log. --Introduction A notification for topic `warning` is sent every time a new `BROKEN`/ `UNUSUAL` level(in plugins, we use `error`/`warn`) log generated, which means an unusual/borken thing happens, such as channel failed, message resolving failed... ```json { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;d better check it; `error` means something extremely bad is out of control, and it may lead to crash; 2. `time` is the second since epoch; 3. `source`, in fact, is the `prefix` of the log_entry. It means where the event happened, it may have the following forms: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `plugin-manager`; 4. `log` is the context of the original log entry. --Note: 1. The main code uses `UNUSUAL`/`BROKEN`, and plugin module uses `warn` /`error`, considering the consistency with plugin, warning choose `warn` /`error`. But users who use c-lightning with plugins may want to `getlog` with specified level when receive warning. It&#39;s the duty for plugin dev to turn `warn`/`error` into `UNUSUAL`/`BROKEN` and present it to the users, or pass it directly to `getlog`; 2. About time, `json_log()` in `log` module uses the Relative Time, from the time when `log_book` inited to the time when this event happend. But I consider the `UNUSUAL`/`BROKEN` event is rare, and it is very likely to happen after running for a long time, so for users, they will pay more attention to Absolute Time. -- Related Change 1. Remove the definitions of `log`, `log_book`, `log_entry` from `log.c` to `log.h`, then they can be used in warning declaration and definition. 2. Remove `void json_add_time(struct json_stream *result, const char *fieldname, struct timespec ts)` from `log.c` to `json.c`, and add related declaration in `json.h`. Now the notification function in `notification.c` can call it. 2. Add a pointer to `struct lightningd` in `struct log_book`. This may affect the independence of the `log` module, but storing a pointer to `ld` is more direct;
6 years ago
/*'warning' is based on LOG_UNUSUAL/LOG_BROKEN level log
*(in plugin module, they're 'warn'/'error' level). */
void notify_warning(struct lightningd *ld, struct log_entry *l)
{
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "warning");
plugin: Add new notification type: warning This notification bases on `LOG_BROKEN` and `LOG_UNUSUAL` level log. --Introduction A notification for topic `warning` is sent every time a new `BROKEN`/ `UNUSUAL` level(in plugins, we use `error`/`warn`) log generated, which means an unusual/borken thing happens, such as channel failed, message resolving failed... ```json { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;d better check it; `error` means something extremely bad is out of control, and it may lead to crash; 2. `time` is the second since epoch; 3. `source`, in fact, is the `prefix` of the log_entry. It means where the event happened, it may have the following forms: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `plugin-manager`; 4. `log` is the context of the original log entry. --Note: 1. The main code uses `UNUSUAL`/`BROKEN`, and plugin module uses `warn` /`error`, considering the consistency with plugin, warning choose `warn` /`error`. But users who use c-lightning with plugins may want to `getlog` with specified level when receive warning. It&#39;s the duty for plugin dev to turn `warn`/`error` into `UNUSUAL`/`BROKEN` and present it to the users, or pass it directly to `getlog`; 2. About time, `json_log()` in `log` module uses the Relative Time, from the time when `log_book` inited to the time when this event happend. But I consider the `UNUSUAL`/`BROKEN` event is rare, and it is very likely to happen after running for a long time, so for users, they will pay more attention to Absolute Time. -- Related Change 1. Remove the definitions of `log`, `log_book`, `log_entry` from `log.c` to `log.h`, then they can be used in warning declaration and definition. 2. Remove `void json_add_time(struct json_stream *result, const char *fieldname, struct timespec ts)` from `log.c` to `json.c`, and add related declaration in `json.h`. Now the notification function in `notification.c` can call it. 2. Add a pointer to `struct lightningd` in `struct log_book`. This may affect the independence of the `log` module, but storing a pointer to `ld` is more direct;
6 years ago
json_object_start(n->stream, "warning");
/* Choose "BROKEN"/"UNUSUAL" to keep consistent with the habit
* of plugin. But this may confuses the users who want to 'getlog'
* with the level indicated by notifications. It is the duty of a
* plugin to eliminate this misunderstanding.
*/
json_add_string(n->stream, "level",
l->level == LOG_BROKEN ? "error"
: "warn");
/* unsuaul/broken event is rare, plugin pay more attentions on
* the absolute time, like when channels failed. */
json_add_time(n->stream, "time", l->time.ts);
json_add_string(n->stream, "source", l->prefix);
json_add_string(n->stream, "log", l->log);
json_object_end(n->stream); /* .warning */
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
void notify_invoice_payment(struct lightningd *ld, struct amount_msat amount,
struct preimage preimage, const struct json_escape *label)
{
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "invoice_payment");
json_object_start(n->stream, "invoice_payment");
json_add_string(n->stream, "msat",
type_to_string(tmpctx, struct amount_msat, &amount));
json_add_hex(n->stream, "preimage", &preimage, sizeof(preimage));
json_add_escaped_string(n->stream, "label", label);
json_object_end(n->stream);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
void notify_channel_opened(struct lightningd *ld, struct node_id *node_id,
struct amount_sat *funding_sat, struct bitcoin_txid *funding_txid,
bool *funding_locked)
{
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "channel_opened");
json_object_start(n->stream, "channel_opened");
json_add_node_id(n->stream, "id", node_id);
json_add_amount_sat_only(n->stream, "amount", *funding_sat);
json_add_txid(n->stream, "funding_txid", funding_txid);
json_add_bool(n->stream, "funding_locked", funding_locked);
json_object_end(n->stream);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}