|
|
51CTO旗下网站
|
|
移动端

2.4.5.2 聚合事件

《Microsoft Azure 管理与开发(下册)平台服务PaaS》本书由世纪互联蓝云Microsoft Azure 开发技术支持团队的资深工程师们编写,主要阐述MicrosoftAzure PaaS 服务的开发应用,涉及计算服务、集成认证服务、数据存储服务、大数据服务等方面的内容。本节为大家介绍聚合事件。

作者:世纪互联蓝云公司来源:电子工业出版社|2018-07-13 09:54

2.4.5.2 聚合事件

Service Fabric 提供了很多类型的事件日志,并且不同事件日志存储的位置和节点也不尽相同,这样就对分析问题带来了很大的不便。所以在分析事件之前,需要将所有的事件日志聚合起来,以便统一处理。Service Fabric 提供两种方式来收集信息,一种是使用EventFlow 的方式,一种是使用Azure 诊断功能。两者都是将Service Fabric 产生日志事件导出到Azure Insight 或者Storage 中,以便后续的分析。

1. 使用EventFlow 聚合事件

EventFlow 是在应用服务项目中进行配置的。将Servcie Fabric 中EventSource 生成的系统和应用日志以及运行状况报告等,导出到Azure Insight,Eventhub 或者Storage。EventFlow 运行在应用程序服务进程内,而且它会建立到输出目标的连接,通过管道的形式向输出目标发送事件日志。这样就会占据应用服务进程的网路资源。因为Service Fabric会将所有相同ServiceType 的副本都放置到一个进程中运行,所以在同一个进程里面可能会有多个EventFlow 同时保持对外的连接。在设计应用时,应该综合考虑EventFlow 的这一限制。

在应用程序中使用EventFlow,需要引入Micorosoft.Diagnotics.EventFlow 相关的DDL包。在NuGet 中查询相关的包,除了需要引入EventFlow 基础包外,还需要引入EventFlow重要的两个组成部分Input 和Output。Input 包代表了聚合信息的来源,可以使用EventSource,ETW,PerformanceCounter 以及Microsoft Logging。Output 则代表聚合的信息的输出目标。EventFlow 支持很多种Output,例如Azure Insight,EventHub,Elasticsearch 以及Oms 等。

在引入EventFlow 的包后,就可以在PackageRoot 的目录下,添加EventFlow 的配置文件eventFlowConfig.json。以下是EventFlow 配置文件的示例代码:

  1. {  
  2. "inputs": [  
  3. {  
  4. "type": "EventSource",  
  5. "sources": [  
  6. { "providerName": "Microsoft-ServiceFabric-Services" },  
  7. { "providerName": "Microsoft-ServiceFabric-Actors" },  
  8. // (replace the following value with your service's ServiceEventSource  
  9. name)  
  10. { "providerName": "your-service-EventSource-name" }  
  11. ]  
  12. }  
  13. ],  
  14. "filters": [  
  15. {  
  16. "type": "drop",  
  17. "include": "Level == Verbose"  
  18. }  
  19. ],  
  20. "outputs": [  
  21. {  
  22. "type": "ApplicationInsights",  
  23. // (replace the following value with your AI resource's instrumentation  
  24. key)  
  25. "instrumentationKey": "00000000-0000-0000-0000-000000000000"  
  26. }  
  27. ],  
  28. "schemaVersion": "2016-08-11"  

将EventSource 的事件日志聚合到Azure Insight 中。EventFlow 允许配置多种Input,并且可以设置filter,过滤传输的事件日志,以减少网络占用。

当配置之后,就可以在服务代码中初始化EventFLow,初始化的过程必须在服务注册之前进行。如下C#代码中,CreatePipeline 方法就是在创建日志聚合管道。如果管道出现问题时,会以管道名称信息报告服务运行状况报告。

  1. var diagnosticsPipeline = ServiceFabricDiagnosticPipelineFactory.  
  2. CreatePipeline("MyApplication-MyService-DiagnosticsPipeline") 

目前Azure Insight 还未在中国上线,可以使用其他服务来聚合事件。例如Eventhubs或者Oms 等。因为Diagnostics-EventFlow 是微软的开源项目,可以在Github 上了解关于Diagnostics-EventFlow 更详细的用法。

2. 使用Azure 诊断聚合事件

使用Microsoft Azure 诊断扩展聚合事件日志,是Azure 比较常用的诊断手段,大部分服务都支持Microsoft Azure 诊断。借助它,可以将Service Fabric 群集生成的所有事件日志信息,全部聚合到Azure 存储、Azure Insight 或者EventHubs 中。也可以使用第三方的日志分析系统(Oms)从存储或者Eventhubs 中读取聚合的日志进行分析。

Microsoft Azure 诊断扩展是安装到群集的每个虚拟机内的。诊断日志收集程序会定期收集虚拟机内部的日志,然后将其同步到配置的存储账户中。建议在创建Service Fabric 时就开启Azure 诊断功能,开启的方式有两种,一种是通过管理门户的方式,一种是通过Azure资源管理模板的方式。

目前管理门户只能在创建Service Fabric 时开启Azure 诊断功能,如果在创建时没有开启,后续只能通过Azure 资源管理模板的形式开启,开启方式如图2.4.6 所示。操作选择较为简单,只需要选择开启即可。创建后,门户会自动创建诊断日志收集存储账号。

通过资源模板创建的方式比较灵活,不仅可以配置Azure 诊断对应的输出的存储账户,也可以进行Azure 诊断配置。

首先,需要在资源管理模板中添加聚合日志输出的存储账号资源,可以使用已存在的存储账号,也可以为Service Fabric 群集建立新的存储账号,但要保证存储账号必须和群集在同一个数据中心。存储账号资源模板的示例代码如下:

  1. {  
  2. "apiVersion": "2015-05-01-preview",  
  3. "type": "Microsoft.Storage/storageAccounts",  
  4. "name": "[parameters('ApplicationDiagnosticsStorageAccountName')]",  
  5. "location": "[parameters('computeLocation')]",  
  6. "properties": {  
  7. " accountType " : " [parameters('ApplicationDiagnosticsStorage  
  8. AccountType')]"  
  9. },  
  10. "tags": {  
  11. "resourceType": "Service Fabric",  
  12. "clusterName": "[parameters('clusterName')]"  
  13. }  

之后,需要在模板中修改群集虚拟机的VirtualMachineProfile,为群集虚拟机添加Azure诊断扩展。Azure 诊断扩展代码示例如下:

  1. {  
  2. " name " : " [concat(parameters('vmNodeType0Name'),'_Microsoft.  
  3. Insights.VMDiagnosticsSettings')]",  
  4. "properties": {  
  5. "type": "IaaSDiagnostics",  
  6. "autoUpgradeMinorVersion": true,  
  7. "protectedSettings": {  
  8. " storageAccountName " : " [parameters('ApplicationDiagnostics  
  9. StorageAccountName')]",  
  10. " storageAccountKey ": " [listKeys(resourceId('Microsoft.Storage/  
  11. storageAccounts', parameters('ApplicationDiagnosticsStorageAccountName')),  
  12. '2015-05-01-preview').key1]",  
  13. "storageAccountEndPoint": "https://core.windows.net/"  
  14. },  
  15. "publisher": "Microsoft.Azure.Diagnostics",  
  16. "settings": {  
  17. "WadCfg": {  
  18. "DiagnosticMonitorConfiguration": {  
  19. "overallQuotaInMB": "50000",  
  20. "EtwProviders": {  
  21. "EtwEventSourceProviderConfiguration": [  
  22. {  
  23. "provider": "Microsoft-ServiceFabric-Actors",  
  24. "scheduledTransferKeywordFilter": "1",  
  25. "scheduledTransferPeriod": "PT5M",  
  26. "DefaultEvents": {  
  27. " eventDestination " : " ServiceFabricReliable  
  28. ActorEventTable"  
  29. }  
  30. },  
  31. {  
  32. "provider": "Microsoft-ServiceFabric-Services",  
  33. "scheduledTransferPeriod": "PT5M",  
  34. "DefaultEvents": {  
  35. " eventDestination " : " ServiceFabricReliableService  
  36. EventTable"  
  37. }  
  38. }  
  39. ],  
  40. "EtwManifestProviderConfiguration": [  
  41. {  
  42. "provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",  
  43. "scheduledTransferLogLevelFilter": "Information",  
  44. "scheduledTransferKeywordFilter": "4611686018427387904",  
  45. "scheduledTransferPeriod": "PT5M",  
  46. "DefaultEvents": {  
  47. "eventDestination": "ServiceFabricSystemEventTable"  
  48. }  
  49. }  
  50. ]  
  51. }  
  52. }  
  53. },  
  54. " StorageAccount " : " [parameters('ApplicationDiagnosticsStorage  
  55. AccountName')]"  
  56. },  
  57. "typeHandlerVersion": "1.5"  
  58. }  

在修改完之后,就可以重新部署模板来发布设置。当发布状态从ProvisioningState 变换为Succeed 时,表明已修改成功,这时Service Fabric 就成功开启Azure 诊断功能。可以在对应配置的存储账号中,看到在模板中配置的表信息,例如:ServiceFabricSystemEventTable,erviceFabricReliableActorEventTableh 等。

在开启Azure 诊断时,需要配置Azure 诊断扩展的WadCfg 设置,来调整聚合日志的范围,可以修改EtwProviders 来收集更多ETW 事件,例如示例模板中的EtwEventSourceProviderConfiguration 和EtwManifestProviderConfiguration。其中EtwEventSourceProviderConfiguration 用来收集EventSource 产生的事件日志,可以在其下添加如下配置,来收集应用服务中产生事件日志,也可以使用系统日志的提供者名称来收集Reliable Services 和Reliable Actors 的系统级别的事件日志。

  1. {  
  2. "provider": "My-Eventsource",  
  3. "scheduledTransferPeriod": "PT5M",  
  4. "DefaultEvents": {  
  5. "eventDestination": "MyDestinationTableName"  
  6. }  

EtwManifestProviderConfiguration 主要是Service Fabric 群集的运行状况报告、负载监视数据等。这里面不仅包含群集系统级别的报告,也包含应用级别的日志。

当通过其中任何一种聚合日志的方式,将Service Fabric 的运行状况报告、EventSource事件,以及资源负载监视数据聚合在一起时,就可以针对这些数据进行分析。可以使用Azure Application Insight 服务或者其他第三方的日志分析程序(例如OMS)进行分析,并生成可视化的监视图标,提供自动化的警报服务;可以借助Service Fabric 和Azure 提供的工具和SDK 来实现整套监控和诊断系统。因为Azure Insight 服务尚未在中国上线,所以对于分析事件这一部分,就不在本书中进行介绍。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

SQL应用与开发标准教程

本书主要介绍了SQL的数据库应用和开发技术,内容涉及关系数据库和SQL概述,SQL环境,SQL对于数据表的操作,数据库查询知识,SQL数据的修改...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊