1. Why develop this feature, and plan Because the misoperation and data model changes in the collector upgrade process may cause some registration data to be lost, if there is a new agent registration, you may get the same id as the agent that lost the metadata, then the subsequent metrics and traces, Not allowed. For the loss of metadata, there are two kinds of compensation mechanisms, the agent resends the data in the memory, and the agent re-registers.
1.1 Re-send The agent directly causes the agent to send the data in the memory to the collector, and the collector to the es. However, since it is serially registered, it may be overwritten by the registered data after the es is written. Therefore, this scheme is not adopted. 1.2 Re-registration Trigger re-registration by setting the id in the agent-side cache to null 1.2.1 What method is used? There are two ways to re-register, manual triggering and automatic triggering. 1.2.1.1 Automatic triggering Loss of metadata due to misoperation is not a defect in the skywalking system. If the reset causes the id of the data before and after the agent to be inconsistent, an exception needs to be thrown to inform the user that his operation has caused the metadata to be lost. Therefore, the method of manually triggering the reset is adopted. 1.2.1.2 Manual trigger If you choose to manually send commands in the management interface, you need to know which agent registration data is lost. Obviously, the metadata has been lost and there is no way to get it. Similarly, the collector side cannot be manually implemented. 1.2.2 How to identify the agent that needs to be re-registered Uniquely determine the instance location by adding the instance_code attribute to the agent.conf configuration file. [ Full content available at: https://github.com/apache/incubator-skywalking/issues/1585 ] This message was relayed via gitbox.apache.org for [email protected]
