DocsICP FilingConsole
官方文档
首页

Log applications

更新时间：
复制 MD 格式
产品详情
我的收藏

Usage limits for SLS log applications, including Log Audit Service.

Log Audit Service

  • Storage methods and region limitations

    Important

    Before using Log Audit Service for regional or centralized storage, ensure the storage region meets legal, regulatory, and security compliance requirements.

    • Centralized storage

      Logs collected from different Alibaba Cloud accounts and regions are stored in a central project that belongs to the central account. The following regions are available for centralized storage.

      Note

      If you switch the region of the central account, Simple Log Service (SLS) creates a new central project. The original project is not deleted.

      • China: China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Hangzhou), China (Shanghai), China (Shenzhen), and China (Hong Kong)

      • Regions outside China: Singapore, Japan (Tokyo), Germany (Frankfurt), Indonesia (Jakarta), and Malaysia (Kuala Lumpur)

    • Regional storage

      For SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS, Log Audit Service supports regional storage. Logs collected from each account are stored in an SLS project that belongs to the central account. The project is in the same region as the source instance. For example, OSS access logs from an instance in the China (Hangzhou) region are stored in a project in the China (Hangzhou) region.

    • Sync to center

      For regional storage of SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS logs, you can sync logstores from different regions to a central logstore. This enables centralized queries, analysis, alerting, visualization, and custom development.

      Note

      The sync mechanism relies on the data transformation feature of SLS. To avoid impacting the sync speed, we recommend that you promptly adjust resources such as shards of the regional logstore based on the data transformation performance guide.

  • Resource limitations

    • Only one central project can exist for the central account. The project is named slsaudit-center-CentralAccountID-ConfiguredRegion, for example, slsaudit-center-117938634953****-cn-beijing. You cannot delete the central project in the console. To delete it, you must use the command line or an API.

    • For SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS, you can have multiple regional projects. A project is named slsaudit-region-CentralAccountID-CollectionRegion, for example, slsaudit-region-117938634953****-cn-beijing. You cannot delete a regional project in the console. To delete it, you must use the command line or an API.

    • After you configure log collection for a cloud product, Log Audit Service creates a dedicated logstore. This logstore has all the features of a standard SLS logstore, with the following exceptions.

      • To prevent data tampering, you cannot write data to the logstore or modify or delete its index.

      • To modify the storage duration or delete the logstore, you must use the Log Audit Service configuration page or an API.

      • For SLB, ALB, OSS, PolarDB-X 1.0, VPC, and DNS, if you enable the Synchronization to Central Project feature, Log Audit Service creates a data transformation task in the corresponding regional project.

        • The data transformation task is named Internal Job: SLS Audit Service Data Sync for OSS Access, Internal Job: SLS Audit Service Data Sync for SLB, Internal Job: SLS Audit Service Data Sync for ALB, Internal Job: SLS Audit Service Data Sync for DRDS, Internal Job: SLS Audit Service Data Sync for VPC, or Internal Job: SLS Audit Service Data Sync for DNS.

        • To stop this data transformation task, you must use the Log Audit Service configuration page or an API.

        • When you enable the Synchronization to Central Project feature for a regional logstore, the service synchronizes it to a dedicated logstore. You cannot perform any operations on this dedicated logstore. To run queries or perform other operations, you must use the central logstore.

  • Permission limitations

    When you use Log Audit Service to collect Kubernetes logs, such as Kubernetes audit logs, Kubernetes Event Center logs, and Ingress access logs, the following permission limitations apply.

    • Log Audit Service can collect Kubernetes logs only from the central account. It cannot collect Kubernetes logs from member accounts in a multi-account setup.

    • Log Audit Service relies on the data transformation feature to collect Kubernetes logs. If you use Log Audit Service to collect Kubernetes logs, you must grant the central account the following permissions.

      Description

      Central account not upgraded

      Central account upgraded

      Current role of the central account

      sls-audit-service-monitor

      AliyunServiceRoleForSLSAudit

      Additional permissions

      The sls-audit-service-monitor role requires the AliyunLogAuditServiceMonitorAccess permission and the following custom permission (AliyunLogAuditServiceK8sAccess).

      {
    "Version": "1",
    "Statement": [
        {
            "Action": "log:*",
            "Resource": [
                "acs:log:*:*:project/k8s-log-*"
            ],
            "Effect": "Allow"
        }
    ]
}

      Only the AliyunServiceRoleForSLSAudit role is required. No additional permissions are required.

  • Storage duration dependencies

    • The following logs in Log Audit Service are stored in the same logstore (dns_log): internal DNS logs (centralized), public DNS resolution logs, and Global Traffic Manager logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (rds_log): ApsaraDB RDS audit logs, slow query logs, and error logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (polardb_log): PolarDB for MySQL audit logs, slow query logs, and error logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (cloudfirewall_log): Internet firewall traffic logs and VPC firewall traffic logs from Cloud Firewall. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (ddos_log): access logs from Anti-DDoS Proxy (Chinese Mainland), Anti-DDoS Proxy (Outside Chinese Mainland), and Anti-DDoS Origin. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (k8s_log): Kubernetes audit logs and Kubernetes Event Center logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (idaas_log): IDaaS management operation logs and IDaaS user behavior logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (cloudconfig_log): Cloud Config change logs and Cloud Config resource non-compliance logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    • The following logs in Log Audit Service are stored in the same logstore (pam_log): PAM O&M audit logs and PAM operation audit logs. If you enable collection for these logs with different storage durations, the longest duration applies.

    Note

    For the preceding log types that have storage duration dependencies, if you enable both log collection and the intelligent tiered storage feature, the longest configured hot storage duration applies. If you enable log collection for some log types but do not enable the intelligent tiered storage feature for all of them, the intelligent tiered storage feature is disabled by default for the shared logstore.

    For example, you enable collection for ApsaraDB RDS audit logs and error logs. If you enable intelligent tiered storage for both, the longest hot storage duration applies. If you enable intelligent tiered storage only for ApsaraDB RDS audit logs but not for error logs, the intelligent tiered storage feature is disabled for their shared logstore (rds_log).

  • Cloud Config

    • Log Audit Service depends on configuration information from Cloud Config. You must go to the Cloud Config console to enable the service and monitor all your resources.

    • If you want to collect, store, or query Cloud Config logs in Log Audit Service, you must authorize SLS to retrieve logs from Cloud Config. After you grant these permissions, Cloud Config automatically sends the logs to SLS.

    • If you collect logs from multiple accounts by using a resource directory, Log Audit Service automatically enables Cloud Config and integrates with SLS for all accounts in the resource directory after you authorize the central account. If you collect logs from multiple accounts by using custom authorization, you must grant additional permissions to the member accounts after you authorize the central account. For more information, see Use custom authorization to collect and sync logs.

  • Intelligent tiered storage

    The dedicated logstores of Log Audit Service support intelligent tiered storage. Compared with hot storage, IA storage is more cost-effective but delivers lower performance for queries and analysis. Other features, such as alerting, visualization, data transformation, and data shipping, are not affected. For more information, see Manage intelligent tiered storage.

    Note

    Intelligent tiered storage is supported in the following audit center regions: China (Qingdao), China (Beijing), China (Hohhot), China (Hangzhou), China (Shanghai), China (Shenzhen), China (Hong Kong), and Singapore.

    You can enable intelligent tiered storage on the Global Configurations page of Log Audit Service. The hot storage duration must be at least 7 days and cannot exceed the total storage duration. For example, if the total storage duration is 180 days and you set the hot storage duration to 30 days, SLS converts the logs to IA storage after 30 days.

    Note

    Log Audit Service (Legacy) does not allow you to enable Archive Storage on the Global Configurations page. To enable this feature, submit a ticket to add your account to an allowlist. After we add your account to the allowlist, the storage duration that you specify in the global configurations takes effect only when you first create the logstore. The logstore console displays the actual storage duration.

  • Data encryption

    Log Audit Service supports encryption using SLS-provided service keys, but does not support Bring Your Own Key (BYOK). The service key encryption method supports the AES algorithm (default) and the SM4 algorithm. For more information, see Data encryption.

    After you enable log encryption, SLS automatically encrypts the dedicated logstores for cloud products that have log collection enabled. This includes logstores in both central and regional projects. For more information, see Enable encryption.

  • Index limitations

    Log Audit Service supports automatic index updates and manual index modification. For more information, see Create an index.

    If you receive the prompt This Logstore is dedicated to the Log Audit Service application. You cannot modify the index attributes of the Logstore or disable indexing. when you modify an index, go to the Global Configurations page of Log Audit Service, click Modify, and then click OK to rebuild the Log Audit Service configuration.

    Important

    Manually modifying an index may cause built-in dashboards and alerts to become unavailable. Use this feature with caution.

Previous：AlertingNext：Supported regions