2018-12-12 14:36:11 +01:00
|
|
|
#ifndef LIGHTNING_LIGHTNINGD_NOTIFICATION_H
|
|
|
|
|
#define LIGHTNING_LIGHTNINGD_NOTIFICATION_H
|
|
|
|
|
#include "config.h"
|
2019-07-25 16:11:44 +02:00
|
|
|
#include <bitcoin/short_channel_id.h>
|
|
|
|
|
#include <bitcoin/tx.h>
|
2019-07-21 13:39:15 +02:00
|
|
|
#include <ccan/json_escape/json_escape.h>
|
|
|
|
|
#include <common/amount.h>
|
2019-07-25 16:11:44 +02:00
|
|
|
#include <common/node_id.h>
|
2018-12-12 14:36:11 +01:00
|
|
|
#include <lightningd/jsonrpc.h>
|
2018-12-13 13:58:40 +01:00
|
|
|
#include <lightningd/lightningd.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
{
"warning": {
"level": "warn",
"time": "1559743608.565342521",
"source": "lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:",
"log": "Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg"
}
}
```
1. `level` is `warn` or `error`:
`warn` means something seems bad happened and it's under control, but
we'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:
`<node_id> chan #<db_id_of_channel>:`, `lightningd(<lightningd_pid>):`,
`plugin-<plugin_name>:`, `<daemon_name>(<daemon_pid>):`, `jsonrpc:`,
`jcon fd <error_fd_to_jsonrpc>:`, `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'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;
2019-06-03 20:26:58 +02:00
|
|
|
#include <lightningd/log.h>
|
2018-12-12 14:36:11 +01:00
|
|
|
#include <lightningd/plugin.h>
|
|
|
|
|
|
|
|
|
|
bool notifications_have_topic(const char *topic);
|
|
|
|
|
|
2019-04-08 11:58:32 +02:00
|
|
|
void notify_connect(struct lightningd *ld, struct node_id *nodeid,
|
2018-12-13 13:58:40 +01:00
|
|
|
struct wireaddr_internal *addr);
|
2019-04-08 11:58:32 +02:00
|
|
|
void notify_disconnect(struct lightningd *ld, struct node_id *nodeid);
|
2018-12-13 13:58:40 +01:00
|
|
|
|
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
{
"warning": {
"level": "warn",
"time": "1559743608.565342521",
"source": "lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:",
"log": "Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg"
}
}
```
1. `level` is `warn` or `error`:
`warn` means something seems bad happened and it's under control, but
we'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:
`<node_id> chan #<db_id_of_channel>:`, `lightningd(<lightningd_pid>):`,
`plugin-<plugin_name>:`, `<daemon_name>(<daemon_pid>):`, `jsonrpc:`,
`jcon fd <error_fd_to_jsonrpc>:`, `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'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;
2019-06-03 20:26:58 +02:00
|
|
|
void notify_warning(struct lightningd *ld, struct log_entry *l);
|
|
|
|
|
|
2019-07-21 13:39:15 +02:00
|
|
|
void notify_invoice_payment(struct lightningd *ld, struct amount_msat amount,
|
|
|
|
|
struct preimage preimage, const struct json_escape *label);
|
|
|
|
|
|
2019-07-25 16:11:44 +02:00
|
|
|
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);
|
|
|
|
|
|
2018-12-12 14:36:11 +01:00
|
|
|
#endif /* LIGHTNING_LIGHTNINGD_NOTIFICATION_H */
|
