We are testing instana apm tool, and one of our server host a msmq application. Instana reports every calls as erroneous and gives no error message.
It states as:
Erroneous call without error message
What does it mean? I found some documents but couldn't understand:
Instana automatically collect logs with level WARN and ERROR (and equivalent, depending on the logging framework). In the image above, a call is erroneous and has one error log associated with it. However, in general a call might be erroneous without having error logs associated with it, and vice-versa.
If there is no error message or error code, how instana determines these calls as Erroneous?
Instana instruments frameworks and libraries, such as msmq, at the method level. If a method returns with an error or throws an exception, Instana will detect this and mark the method call as erroneous. This will happen independently of any configured logging framework. If a supported logging framework is configured, Instana will also collect the log message for further information.
Related
AuditTo is a Serilog feature that ensures synchronous write to the sink, with an exception thrown if change flushing fails.As the name implies, it is ideal for ensuring the security of audit data to be stored. Right now, I found File, Seq and RabbitMQ sinks supporting AuditTo writes. I couldn't find the SqlLite sink that I'm interested in ... :(
From the other side, we have WriteTo, which batches the log entries and writes them asynchronously. There are no exceptions; it's kind of fire and forget.No one cares whether the log entries are dropped by the connection or the target system's failure or unavailability.
I would like to implement sending the audit logs via AuditTo but also be able to switch the log configuration to WriteTo at the runtime. In the meantime, the app might still write the logs.
I saw that Serilog offers dynamic switching of the logging level via LoggingLevelSwitch.
Any suggestions, ideas, or solutions for such requirements?
We are having a setup where we are using spring-amqp transacted channels to push our messages to RabbitMq. During a testing we found that messages were not even getting published from spring-amqp to rabbitmq;
we suspect metricsCollector.basicPublish(this) in com.rabbitmq.client.impl.ChannelN failure(no exception is thrown).
because we can see that RabbitUtils.commitIfNecessary(channel) in org.springframework.amqp.rabbit.core.RabbitTemplate is not getting called when there is an issue executing metricsCollector.basicPublish(this) for the same code flow.
We have taken TCP dumps and could see that message were written to stream/socket on rabbitmq, but since commit didn't happen due to an a probable amqp api failure the messages were not delivered to corresponding queues.
Jars Version Being used in the setup:-
spring-amqp-2.2.1.RELEASE.jar,
spring-rabbit-2.2.1.RELEASE.jar
amqp-client-5.7.3.jar,
metrics-core-3.0.2.jar
Is anyone facing the similar issue?
Can someone please help.
---edit 1
(Setup) :- We are using same connection Factory for flows with parent transaction and flows not running with parent transactions
On further analyzing the issue , we found that isChannelLocallyTransacted is sometimes showing in-consistent behavior because ConnectionFactoryUtils.isChannelTransactional(channel, getConnectionFactory() is sometimes having a reference to transacted channel (returns true hence expression isChannelLocallyTransacted evaluates to false) due to which tx.commit never happens; so message gets lost before getting committed to RabbitMQ.
I know both error_logger and error_logger_tty_h are swappable handlers of gen_event error_logger.
From their source code, I know error_logger report messages ending up erlang:display, and error_logger_tty_h ending up `io:format(user, String, Args)
What I feel confused is, what difference between error_logger and error_logger_tty_h for purposes?
This is mostly documented in http://erlang.org/doc/man/error_logger.html, but basically, the error_logger module implements the API for starting and interacting with the gen_event server or "event manager" which is also named error_logger. This process will receive the events and pass them to the registered handlers. The API module includes functions like error_msg(...) for sending the actual event messages in the correct format expected by the server.
However - the error_logger module also implements gen_event callback functions so that it can be registered as a handler for the server. This code could (and perhaps should) have been placed in a separate module, but the advantage is that it is trivially known that the callback code is already loaded when the error logger starts.
The error logger is started by the Erlang boot script, before any application - including the kernel app - has been started. At that time, very little is known about the capabilities of the system, but basic error logging still needs to work. The callbacks in the error_logger module implement primitive logging that print any errors during this early phase straight to the stdout of the Beam runtime process - which might just be to a console or /dev/null. It also buffers up to a fixed number of messages to be passed on to a better handler later on.
When the kernel application starts, it will read the kernel app environment settings and swap the error_logger handler to the kind you really want for the system, such as error_logger_tty_h or error_logger_file_h. It will also get any buffered messages from the old logger when it takes over, so it can handle them properly.
That's not quite the end of the story, though, because the error_logger module will still be registered as a handler for the event manager. In this new role it doesn't do any printing or buffering, but it is responsible for forwarding any events to the Erlang node corresponding to the group leader process of the process that dispatched the event. This ensures that error logger events always make their way "home" to be logged on the node of their group leader process.
I went through the documentation of the trace/3 BIF in Erlang. However, one observation I have made is that it cannot be used for tracing the consuming of messages from the mailbox. The flag 'receive' only traces when messages are added to a process's mailbox.
Is there any way one can trace events such as reading from the mailbox using the receive construct? If not, is there any reason why this isn't possible? It seems very strange that one can trace most kind of events in a program and the reading of messages from a mailbox is not traceable.
There is no such tool. You can only hope for call tracing of the handling function. It is rather easy in OTP applications since you can hook handle_....
We are using Nagios to monitor our network with great results. There is now a new requirement we are struggling with:
We want to notify Nagios of an non
fatal but critical application errors. The
application does not stop running but
there is some sort of issue that
needs looking into.
Once the issue has been looked into,
we need some way to "unflag" the
issue in Nagios.
We tried using the syslog, but the biggest problem was once an error was logged, the service was put into an error state with no way to recover. Also, while applications would report a critical error to the syslog, most of the time they don't report an "All clear" error.
I've done this using passive checks: http://nagios.sourceforge.net/docs/3_0/passivechecks.html
Basically, you're application is just going to feed the nagios core some data into its external command file. Nagios will eventually read the data and update the alerts, execute event handlers, etc.
Exactly how you set this up will be unique for your case, but if you need any other help just let me know. :)