# AxoSyslog Onboarding allows you to collect metrics about the host, display the host on the **Topology** page, and to tap into the log flow. Onboarding requires you to modify the host and the configuration of the logging agent (AxoSyslog) running on the host. * Level 1: Install Axolet on the host where AxoSyslog is running. Axolet collects metrics from the host and sends them to the AxoConsole, so you can check host-level metrics on the **Metrics & Health** page of the host, and displays the host on the **Topology** page. * Level 2: Instrument the configuration of the logging agent to provide detailed metrics about the traffic flow. This allows you to display data about the host on the **Analytics** page. * Level 3: Instrument the configuration of the logging agent to allow you to access the logs of the logging agent and to [tap into the log flow from the AxoConsole](../../docs/axoflow/onboard-hosts/log-tapping/index.md). The exact steps for this integration depend on the configuration of your logging agent. We provide basic instrumentation instructions for getting started in this guide, but we strongly recommend to [contact us so our professional services can help you with a production integration](). To onboard an existing AxoSyslog instance into Axoflow, complete the following steps. 1. [Install Axolet on the host](../../docs/axoflow/provisioning/axolet/index.md), then approve its registration on the **Provisioning** page of the AxoConsole. 2. The AxoSyslog host is now visible on the **Topology** page of the AxoConsole as a source. 3. Access the AxoSyslog host and edit the configuration of AxoSyslog. Set the statistics-related global options like this (if the `options` block already exists, add these lines to the bottom of the block): ``` options { stats( level(2) freq(0) # Inhibit statistics output to stdout ); }; ``` 4. (Optional) To get detailed[ metrics and analytics](../../docs/axoflow/metrics/index.md) about the traffic that flows through the host, instrument your AxoSyslog configuration as follows: Note You can use Axolet with an un-instrumented AxoSyslog configuration file, but that limits available metrics to host statistics (for example, disk, memory, queue information). You won’t be able to access data about the actual traffic flowing through the host. To collect traffic-related metrics, instrument configuration with `metrics-probe()` stanzas. The example below shows how to instrument the configuration to highlight common macros such as `$HOST` and `$PROTOCOL`. If you want to customize the collected metrics or need help with the instrumentation, [contact us](). 1. Download the following configuration snippet to the AxoSyslog host, for example, as `/etc/syslog-ng/conf.d/axoflow-instrumentation.conf` for AxoSyslog. ``` # Metrics probe parser definition for a specified destination # This will yield a reasonable number of metrics for common # syslog-ng macros block parser metrics-output(destination(undefined)) { # This will probe for the number of *events*. # key name is fixed; labels are user-specified metrics-probe( key("classified_output_events_total") labels( "host" => "${HOST}" "service" => "${PROGRAM}" "source" => "${SOURCE}" "dest_port" => "$DESTPORT" "dest_ip" => "$DESTIP" "src_ip" => "$SOURCEIP" "protocol" => "$(if ($PROTO == 6) TCP $(if ($PROTO == 17) UDP $PROTO))" "ip_protocol" => "$IP_PROTO" "transport" => "$TRANSPORT" "destination_name" => "`destination`" "issue" => "$(or $(tags-head message.parse_error syslog.unexpected_framing syslog.missing_pri syslog.rfc3164_missing_header syslog.invalid_hostname message.utf8_sanitized) 'none')" ) ); # This will probe for the number of *bytes*. # key name is fixed; labels are user-specified metrics-probe( key("classified_output_event_bytes_total") increment("${RAWMSG_SIZE}") labels( "host" => "${HOST}" "service" => "${PROGRAM}" "source" => "${SOURCE}" "dest_port" => "$DESTPORT" "dest_ip" => "$DESTIP" "src_ip" => "$SOURCEIP" "protocol" => "$(if ($PROTO == 6) TCP $(if ($PROTO == 17) UDP $PROTO))" "ip_protocol" => "$IP_PROTO" "transport" => "$TRANSPORT" "destination_name" => "`destination`" "issue" => "$(or $(tags-head message.parse_error syslog.unexpected_framing syslog.missing_pri syslog.rfc3164_missing_header syslog.invalid_hostname message.utf8_sanitized) 'none')" ) ); }; @define AXOTAP_SOCK "/var/lib/syslog-ng/axotap.sock" destination "d_axotap" { channel { filter { rate-limit(key("$SOURCE:$PROGRAM:$HOST:$SOURCEIP:$DESTIP") rate(1)); }; rewrite { set("$(substr ${MESSAGE} 0 32768)" value(MESSAGE)); set("$(substr ${RAWMSG} 0 32768)" value(RAWMSG)); set("$(format-json debug.msg=$(format-json --scope all-nv-pairs) log.body=${MESSAGE})" value(".tap.event")); set('{"note":"message object too long for tapping"}' value(".tap.event") condition("$(length ${.tap.event})" > 131072)); set("$(format-json tap=$(format-json tapId='' eventId=${UNIQID} labels=$(format-json) hostCandidate=$(format-json) facility=${FACILITY} format=${MSGFORMAT} hostFrom=${HOST_FROM} message=$(echo ${MESSAGE}) rawMessage=${RAWMSG} severity=${SEVERITY} source=${SOURCE} tags=${TAGS} timestamp=${ISODATE} transport=${TRANSPORT}) event=json(${.tap.event}))" value(".tap.formatted")); }; destination { unix-dgram("`AXOTAP_SOCK`" template("${.tap.formatted}")); }; }; }; ``` 2. Include it in at the top of your configuration file: ``` @version: current @include "axoflow-instrumentation.conf" ``` 3. Edit every destination statement to include a `parser { metrics-output(destination(my-destination)); };` line (making sure to include the `channel` construct if your destination block does not already contain it): ``` destination my-destination { channel { parser { metrics-output(destination(my-destination)); }; destination { file("/dev/null"); }; }; }; ``` 4. Reload the configuration of AxoSyslog. ``` systemctl reload syslog-ng ``` 5. To enable [log tapping](../../docs/axoflow/onboard-hosts/log-tapping/index.md) for the traffic that flows through the host, add the `d_axotap` destination in your log paths. This allows the Axolet agent to collect rate-limited log samples from that specific point in the pipeline. Note There are multiple ways to add tapping to your configuration, which in some cases can introduce unwanted side effects. [Contact us]() to help you create a safe tapping configuration for your use case! 1. Find a log path that you want to tap into and add the tap destination in a safe way, for example, by adding it in a separate inner log path: ``` log { source(s_udp514); log { destination(d_udp514); }; log { destination(d_axotap); }; }; ``` 2. Reload the configuration of AxoSyslog. ``` systemctl reload syslog-ng ``` 3. Unregister the service so that auto service registration can discover the new tapping point: ![Unregister](/docs/axoflow/img/onboard-hosts/syslog-ng/unregister.png) 4. Test [log tapping](../../docs/axoflow/onboard-hosts/log-tapping/index.md) from the top right menu: ![Open Log tapping](/docs/axoflow/img/onboard-hosts/syslog-ng/tapping-menu.png) 5. If AxoSyslog is sending data to an AxoRouter, create a placeholder [data forwarding rule](../../docs/axoflow/data-sources/data-forwarding/index.md) where the **Edge Selector** matches AxoSyslog and the **Router connector** is the connector of the AxoRouter instance where AxoSyslog is sending the data. This is needed to display AxoSyslog and its data metrics on the **Topology** page, AxoConsole won’t manage AxoSyslog.