问题描述
从文档尚不清楚Azure Application Insights如何回溯到Azure云服务.
From the documentation it is unclear how Azure Application Insights pings back to the Azure cloud service.
这里唯一提供线索的文档并没有确切解释其工作原理.我认为，使计划变得更加困难的是，Azure监视器服务是一项，而通过代码应用的实际应用程序的遥测服务是组成整体的另一部分.
The only documentation here that gives a clue doesn't explain exactly how this works. I think what makes it a little more difficult to plan for is that the Azure monitor service is one piece and then the actual application's telemetry service applied through code is another part to make up the whole.
这是此文档中的声明:
利用本地存储的遥测通道在TEMP或APPDATA目录中创建临时文件，这些文件仅限于运行您的应用程序的特定帐户.当端点暂时不可用或您达到限制极限时，可能会发生这种情况.解决此问题后，遥测通道将恢复发送所有新的和持久的数据.
Telemetry channels that utilize local storage create temp files in the TEMP or APPDATA directories which are restricted to the specific account running your application. This may happen when an endpoint was temporarily unavailable or you hit the throttling limit. Once this issue is resolved, the telemetry channel will resume sending all the new and persisted data.
出于我们的目的，计划将是使用Azure应用程序见解，但连接最多只能是不稳定的或已计划的". IE.每12或24小时.
For our purposes the plan would be to use Azure Application Insights but connectivity would be spotty or "planned" at best. I.e. every 12 or 24 hours.
是否有一种计划何时实际ping和使用该服务的方法，或者是否有一种方法可以仅在特定时间间隔提交日志"?
Is there a way to plan when the service is actually pinged and used or is there a way to just submit "logs" at certain time intervals?
如果没有，那么斑点/间歇性连接通常会发生什么?
If not, what happens with spotty/intermittent connectivity in general?
推荐答案
ServerTelemetryChannel(将数据持久存储在本地存储中的那个)将保存长达24小时，并在建立连接后进行传输.如果没有连接的时间长于连接时间，它将继续尝试，但是一旦连接成功，它不会传输任何超过24小时的信息.还有一个存储大小限制为50 MB.如果您可以每12小时可靠地发送一次数据，那很好，但是没有一种简单的方法可以知道何时传输完所有数据，因此计划的连接需要足够长的时间以确保您可以传输所有数据
The ServerTelemetryChannel, which is the one that persists data in local storage will hold data for up to 24 hours and transmit once it gets a connection. If there is no connectivity for longer than that it will keep trying, but it won't transmit anything older than 24 hours once it does get a connection. There is also a storage size limit of 50 MB. If you can reliably send data once every 12 hours you would be fine, but there isn't an easy way to tell when all the data has been transmitted, so the planned connection needs to be long enough to ensure you can transmit all the data.
另一个选择是创建自己的 ITelemetryChannel，以实现计划的数据传输.由于SDK是开源的，因此您可以使用服务器遥测代码以帮助指导您.
Another option would be to create your own ITelemetryChannel that implements a scheduled data transmission. Since the SDK is open source, you can use the Server Telemetry code to help guide you.
最后的选择是通过其他某种方式将日志持久存储在本地存储中，然后将其导入到Azure Monitor中. 数据收集器API 位于预览，但是只要您使用Monitor可以理解的架构发送数据，它就可以按照您希望的任何时间表将数据导入到Azure Monitor.
The final option would be to persist logs on local storage through some other means and then import them into Azure Monitor. The Data Collector API is in preview, but it would allow you to import data into Azure Monitor on whatever schedule you want as long as it's sent with a schema that Monitor understands.
这篇关于由于间歇性的网络连接，是否可以使用日志在特定的时间间隔向Azure Application Insights报告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！