we installed .net agents on Windows server. The agent shows connected with the server but it showing warning saying "Instrumentation disabled since the agent could not connect during startup" and there is no purepath data available.When we reset the app pool then agents will be active and pulling the purepaths. But this issue is occurring frequently 3 times in a week.could you please suggest how can we sort out this issue.
when i look into agent logs its having very less Average transformation time
2018-05-31 02:00:15 [000005f4] info [native] Average transformation time for 1 classes/modules was 68ms - maximum set to 60000ms
Hello @Shyamala P.
A firewall introduces latency in the calls between the Agent and Collector. This is often the reason for slow application start-up. The Agent needs to do several 10,000 round trips to the Collector at application start up. Even 1 ms firewall latency adds up to a noticeable time. Therefore, either use a real fast (in latency time) firewall or put the Collector into the same subnet as the Agents.
Review the below link for the collector best practices:
To avoid the situation you will have to avoid the firewall and move the collector(s) into the same zones where web/app are residing.
In case you need to install new collector(s) then make sure the IP address and the hostname should be the same especially you used to instrument the web/app.
You can use the migration tool for the data migration.
Let us know in case you need further assistance.
Your original post states that the problem was that the agent could not connect. This is not a Collector location issue directly. If your agent host has trouble connecting to your collector host, then you have a network connection problem, not a latency problem. However relocating your collector can possibly resolve this issue. I would certainly get your network team involved to explore why connections are failing between these two hosts. Putting in multiple collectors, each at more strategically 'local' locations can also help resolve the issue. Putting in collector groups can also help address this issue, providing alternate connection options when one connection fails the initial connection. As always, ensure each agent has an available collector that is 'close' to the agent from a latency perspective. Monitoring the Transformation Time value reported in the agent log provides a quantitative measure of this latency. In your original post, you can see your agent had a Transformation Time of 68ms.
I have had this problem when my collector group was filled with collectors that were accessible with some that weren't. The agent attempts to connect to all collectors in the group and if it's unable it still reports into the server (through a collector it has a route with) but deactivates.
Could this be what's happening for you?