Azure SignalR 服务的资源日志Resource logs for Azure SignalR Service

本教程讨论 Azure SignalR 服务的资源日志是什么、如何设置资源日志,以及如何使用资源日志进行故障排除。This tutorial discusses what resource logs for Azure SignalR Service are, how to set them up, and how to troubleshoot with them.

先决条件Prerequisites

若要启用资源日志,需要指定某个位置用于存储日志数据。To enable resource logs, you'll need somewhere to store your log data. 本教程使用 Azure 存储。This tutorial uses Azure Storage.

  • Azure 存储 - 保留策略审核、静态分析或备份的资源日志。Azure storage - Retains resource logs for policy audit, static analysis, or backup.

设置 Azure SignalR 服务的资源日志Set up resource logs for an Azure SignalR Service

可查看 Azure SignalR 服务的资源日志。You can view resource logs for Azure SignalR Service. 这些日志更详细地展示了与 Azure SignalR 服务实例之间的连接。These logs provide richer view of connectivity to your Azure SignalR Service instance. 资源日志提供每个连接的详细信息。The resource logs provide detailed information of every connection. 例如,连接的基本信息(用户 ID、连接 ID 和传输类型等)和事件信息(连接、断开连接和中止事件等)。For example, basic information (user ID, connection ID and transport type and so on) and event information (connect, disconnect and abort event and so on) of the connection. 资源日志可用于识别问题、跟踪连接和分析。resource logs can be used for issue identification, connection tracking and analysis.

启用资源日志Enable resource logs

资源日志默认已禁用。Resource logs are disabled by default. 若要启用资源日志,请执行以下步骤:To enable resource logs, follow these steps:

  1. Azure 门户中的“监视”下,单击“诊断设置”。 In the Azure portal, under Monitoring, click Diagnostic settings.

    在窗格中导航到诊断设置

  2. 然后单击“添加诊断设置”。Then click Add diagnostic setting.

    添加资源日志

  3. 设置所需的存档目标。Set the archive target that you want. 目前,我们支持“存档到存储帐户”。Currently, we support Archive to a storage account.

  4. 选择要存档的日志。Select the logs you want to archive.

    诊断设置窗格

  5. 保存新的诊断设置。Save the new diagnostics settings.

新设置在大约 10 分钟后生效。New settings take effect in about 10 minutes. 在此之后,日志将出现在“诊断日志”窗格上配置的存档目标中。After that, logs appear in the configured archival target, in the Diagnostics logs pane.

有关配置诊断的详细信息,请参阅 Azure 资源日志概述For more information about configuring diagnostics, see the overview of Azure resource logs.

资源日志类别Resource logs categories

Azure SignalR 服务将资源日志捕获到一个类别中:Azure SignalR Service captures resource logs in one category:

  • 所有日志:跟踪与 Azure SignalR 服务建立的连接。All Logs: Track connections that connect to Azure SignalR Service. 日志提供有关连接/断开连接、身份验证和限制的信息。The logs provide information about the connect/disconnect, authentication and throttling. 有关详细信息,请参阅下一部分。For more information, see the next section.

存档到存储帐户Archive to a storage account

日志存储在“诊断日志”窗格中配置的存储帐户内。Logs are stored in the storage account that configured in Diagnostics logs pane. 系统会自动创建一个名为 insights-logs-alllogs 的容器来存储资源日志。A container named insights-logs-alllogs is created automatically to store resource logs. 日志存储在该容器中的 resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX/y=YYYY/m=MM/d=DD/h=HH/m=00/PT1H.json 文件内。Inside the container, logs are stored in the file resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX/y=YYYY/m=MM/d=DD/h=HH/m=00/PT1H.json. 简单而言,其路径由 resource IDDate Time 组成。Basically, the path is combined by resource ID and Date Time. 日志文件按 hour 拆分。The log files are split by hour. 因此,分钟值始终为 m=00Therefore, the minutes always be m=00.

所有日志均以 JavaScript 对象表示法 (JSON) 格式存储。All logs are stored in JavaScript Object Notation (JSON) format. 每个条目均包含字符串字段,这些字段采用以下部分所述的格式。Each entry has string fields that use the format described in the following sections.

存档日志 JSON 字符串包含下表列出的元素:Archive log JSON strings include elements listed in the following tables:

格式Format

名称Name 说明Description
timetime 日志事件时间Log event time
levellevel 日志事件级别Log event level
ResourceIdresourceId Azure SignalR 服务的资源 IDResource ID of your Azure SignalR Service
locationlocation Azure SignalR 服务的位置Location of your Azure SignalR Service
categorycategory 日志事件的类别Category of the log event
operationNameoperationName 事件的操作名称Operation name of the event
callerIpAddresscallerIpAddress 服务器/客户端的 IP 地址IP address of your server/client
propertiesproperties 与此日志事件相关的详细属性。Detailed properties related to this log event. 有关更多详细信息,请参阅下面的属性表For more detail, see the properties table below

属性表Properties Table

名称Name 说明Description
typetype 日志事件的类型。Type of the log event. 目前,我们提供有关与 Azure SignalR 服务建立的连接的信息。Currently, we provide information about connectivity to the Azure SignalR Service. ConnectivityLogs 类型可用Only ConnectivityLogs type is available
collectioncollection 日志事件的集合。Collection of the log event. 允许的值为:ConnectionAuthorizationThrottlingAllowed values are: Connection, Authorization and Throttling
connectionIdconnectionId 连接的标识Identity of the connection
transportTypetransportType 连接的传输类型。Transport type of the connection. 允许的值为:Websockets | ServerSentEvents | LongPollingAllowed values are: Websockets | ServerSentEvents | LongPolling
connectionTypeconnectionType 连接的类型。Type of the connection. 允许的值为:Server | ClientAllowed values are: Server | Client. Server:从服务器端建立的连接;Client:从客户端建立的连接Server: connection from server side; Client: connection from client side
userIduserId 用户的标识Identity of the user
messagemessage 日志事件的详细消息Detailed message of log event

以下代码是存档日志 JSON 字符串的示例:The following code is an example of an archive log JSON string:

{
    "properties": {
        "message": "Entered Serverless mode.",
        "type": "ConnectivityLogs",
        "collection": "Connection",
        "connectionId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "userId": "User",
        "transportType": "WebSockets",
        "connectionType": "Client"
    },
    "operationName": "ServerlessModeEntered",
    "category": "AllLogs",
    "level": "Informational",
    "callerIpAddress": "xxx.xxx.xxx.xxx",
    "time": "2019-01-01T00:00:00Z",
    "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX",
    "location": "xxxx"
}

使用资源日志进行故障排除Troubleshooting with resource logs

若要对 Azure SignalR 服务进行故障排除,可以启用服务器端/客户端日志来捕获故障。To troubleshoot for Azure SignalR Service, you can enable server/client side logs to capture failures. 目前,Azure SignalR 服务会公开资源日志,你也可以为服务端启用日志。At present, Azure SignalR Service exposes resource logs, you can also enable logs for service side.

遇到连接意外增加或丢失的情况时,可以利用资源日志进行故障排除。When encountering connection unexpected growing or dropping situation, you can take advantage of resource logs to troubleshoot.

典型问题通常与连接的意外数量更改、连接达到限制和授权失败有关。Typical issues are often about connections' unexpected quantity changes, connections reach connection limits and authorization failure. 请参阅下一部分了解如何进行故障排除。See the next sections about how to troubleshoot.

意外的连接数更改Unexpected connection number changes

意外的连接丢失Unexpected connection dropping

如果遇到意外的连接丢失,请先在服务、服务器和客户端启用日志。If you encounter unexpected connections drop, firstly enable logs in service, server and client sides.

如果连接断开,资源日志将记录此断开连接事件;在 ConnectionEndedoperationName 中会看到 ConnectionAbortedIf a connection disconnects, the resource logs will record this disconnecting event, you will see ConnectionAborted or ConnectionEnded in operationName.

ConnectionAbortedConnectionEnded 之间的区别在于,ConnectionEnded 是客户端或服务器端触发的预期断开连接。The difference between ConnectionAborted and ConnectionEnded is that ConnectionEnded is an expected disconnecting which is triggered by client or server side. ConnectionAborted 通常是意外的连接丢失事件,中止原因会在 message 中提供。While the ConnectionAborted is usually an unexpected connection dropping event, and aborting reason will be provided in message.

下表列出了中止原因:The abort reasons are listed in the following table:

ReasonReason 说明Description
连接计数达到限制Connection count reaches limit 连接计数达到当前定价层的限制。Connection count reaches limit of your current price tier. 考虑纵向扩展服务单元Consider scale up service unit
应用程序服务器关闭了连接Application server closed the connection 应用服务器触发了中止。App server triggers the abortion. 可将其视为预期的中止It can be considered as an expected abortion
连接 ping 超时Connection ping timeout 通常,此问题是由网络问题造成的。Usually it is caused by network issue. 考虑从 Internet 检查应用服务器的可用性Consider checking your app server's availability from the internet
服务重新加载并重新连接Service reloading, reconnect Azure SignalR 服务正在重新加载。Azure SignalR Service is reloading. Azure SignalR 支持自动重新连接。可以等到已重新连接,或手动重新连接到 Azure SignalR 服务Azure SignalR supports auto-reconnecting, you can wait until reconnected or manually reconnect to Azure SignalR Service
内部服务器的暂时性错误Internal server transient error Azure SignalR 服务中发生暂时性错误,应可自动恢复Transient error occurs in Azure SignalR Service, should be auto-recovered
服务器连接已丢失Server connection dropped 服务器连接丢失并出现未知错误,请考虑先使用服务/服务器/客户端日志自我进行故障排除。Server connection drops with unknown error, consider self-troubleshooting with service/server/client side log first. 尝试排除基本问题(例如网络问题、应用服务器端问题等)。Try to exclude basic issues (e.g Network issue, app server side issue and so on). 如果问题未解决,请联系我们以获得更多帮助。If the issue isn't resolved, contact us for further help. 有关详细信息,请参阅获取帮助部分。For more information, see Get help section.
意外的连接增加Unexpected connection growing

若要排查连接意外增加的问题,首先需要筛选出额外的连接。To troubleshoot about unexpected connection growing, the first thing you need to do is to filter out the extra connections. 可以向测试客户端连接添加唯一的测试用户 ID。You can add unique test user ID to your test client connection. 然后使用资源日志验证该 ID,如果看到多个客户端连接使用同一测试用户 ID 或 IP,则可能表示客户端创建并建立了超过预期数目的连接。Then verify it in with resource logs, if you see more than one client connections have the same test user ID or IP, then it is likely the client side create and establish more connections than expectation. 检查客户端。Check your client side.

授权失败Authorization failure

如果针对客户端请求返回了“401 未授权”,请检查资源日志。If you get 401 Unauthorized returned for client requests, check your resource logs. 如果遇到 Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>,则表示访问令牌中的所有受众无效。If you encounter Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>, it means all audiences in your access token are invalid. 尝试使用日志中建议的有效受众。Try to use the valid audiences suggested in the log.

限制Throttling

如果发现无法在 SignalR 客户端与 Azure SignalR 服务之间建立连接,请检查资源日志。If you find that you cannot establish SignalR client connections to Azure SignalR Service, check your resource logs. 如果在资源日志中遇到 Connection count reaches limit,则表示与 SignalR 服务建立的连接过多,从而达到了连接计数限制。If you encounter Connection count reaches limit in resource log, you establish too many connections to SignalR Service, which reach the connection count limit. 考虑纵向扩展 SignalR 服务。Consider scaling up your SignalR Service. 如果在资源日志中遇到 Message count reaches limit,则表示使用的是免费层,并且已用完了消息配额。If you encounter Message count reaches limit in resource log, it means you use free tier, and you use up the quota of messages. 若要发送更多消息,请考虑将 SignalR 服务更改为标准层。If you want to send more messages, consider changing your SignalR Service to standard tier to send additional messages. 有关详细信息,请参阅 Azure SignalR 服务定价For more information, see Azure SignalR Service Pricing.

获取帮助Get help

我们建议先自行排查问题。We recommend you troubleshoot by yourself first. 大多数问题都是由应用服务器或网络问题造成的。Most issues are caused by app server or network issues. 遵循使用资源日志进行故障排除的指南基本故障排除指南找出根本原因。Follow troubleshooting guide with resource log and basic trouble shooting guide to find the root cause. 如果依然无法解决问题,请考虑在 GitHub 中提出问题或者在 Azure 门户中创建票证。If the issue still can't be resolved, then consider open an issue in GitHub or create ticket in Azure Portal. 提供:Provide:

  1. 问题发生前后大约 30 分钟的时间范围Time range about 30 minutes when the issue occurs
  2. Azure SignalR 服务的资源 IDAzure SignalR Service's resource ID
  3. 问题详情,越具体越好:例如,应用服务器不发送消息、客户端连接丢失,等等Issue details, as specific as possible: For example, appserver doesn't send messages, client connection drops and so on
  4. 从服务器/客户端以及其他可能有用的材料收集的日志Logs collected from server/client side, and other material that might be useful
  5. [可选] 重现代码[Optional] Repro code

备注

如果在 GitHub 中提出问题,请将你的敏感信息(例如资源 ID、服务器/客户端日志)保密,并只以私密方式发送到 Microsoft 组织中的成员。If you open issue in GitHub, keep your sensitive information (For example, resource ID, server/client logs) private, only send to members in Microsoft organization privately.