Ladění a monitoring
- Ladění a monitoring
Tohle asi částečně použitelné bude, ale chce na tyto principy použít moderní metody. Navíc tam teď asi máme nějako novinky.
This section describes common diagnostic tasks to help you verify Normalization Pipeline work correctly. At the moment this is done by analyzing the output - Runtime Topics.
Very useful way to tell if Pipeline works the way it should is to examine the output - Runtime topics. You can use Admin UI topic viewer, or you can inspect the topics in developer console. Unfortunately, third-party tools cannot be used, because messages are encoded with Erlang ETF, which is usually not supported. Admin UI offers quick and simple access to topics, just go to Topics section and locate the topic. However, in Admin UI it might be difficult to analyze really big messages, finding relationships or computing aggregates. For such diagnostic it’s better to use the developer console.
Developer console allows you to not only visually inspect the messages but also execute code that
inspects the topic for you. First enter the developer console. You can use the script placed in your deployment -
utils/console.sh. You can call the following APIs to inspect the topic. The complete set can be
found here, these are the most important.
Normalizer.list_topics()- lists all existing topics.Normalizer.inspect_topics()- lists all topics and provides some meta-information about each.Normalizer.inspect_rt_topic(topic, start_from, number_of_messages)- returns an exact number of messages at the specified time. Good to quickly retrieve some messages to inspect them in detail.Normalizer.stream_rt_topic(topic, start_from)- returns a Stream of messages from the specified time. Good for processing a larger amount of messages. It is recommended to read up on Streams to be most effective with them.
All APIs discard ticks by default but if you want you can include them, see the function documentation for details.
Each Pipeline creates multiple Runtime topics. If the pipeline is named MyData_1 it creates the
following.
NX_rt_MyData_1- the main topic, successfully normalized messages go here. This topic is consumed by Scenarios, so make sure this topic has all the data you need.NX_rt_MyData_1_error- the error topic, it contains messages that the Pipeline could not parse. Pipeline can also verify the message is parsed correctly, has correct types and values, if some of these checks fail the messages are also placed in the error topic. This topic should ideally be empty.NX_rt_MyData_1_jitter- the jitter topic, it contains out-of-order messages, which Pipeline wasn’t able to sort into the resulting stream. These were received either too early or too late (most common). The difference between the external and arrival time should be at most half of the reorder window (reorder_threshold). This topic should ideally be empty, although sometimes you might naturally get few out-of-order messages.
The X is Runtime Topic Version, and is just some small integer. It represents the internal
version of the topic format. If we need to change the topic serialization format we can increase
this number and all topics will be recomputed.
ALTWORX provides built-in topic diagnostic which helps you quickly see the message distribution in the topic. It shows how many messages are in the last minutes, hours, days and weeks. Using this tool you can quickly see the distribution of messages and can assess whether there’s some more intricate problem, e.g. only a subset of message are coming in.
Topic diagnostic is available in Admin UI - open up the topic in Topic viewer and toggle to
Diagnostics in the top/right corner. Developer console provides
Normalizer.pipelines_diagnostics() which
returns diagnostic information for all running pipelines.
Topic diagnostics only inspects the last 10000 messages by default, if you see at least X in the output, it means the interval wasn’t read in its entirety and therefore, we only know there’s at least X messages in the interval, there could be more.