Azure Cache for Redis-adatok monitorozása a diagnosztikai beállítások használatával
Cikk
Az Azure-ban a diagnosztikai beállítások az erőforrásnaplók gyűjtésére szolgálnak. Az Azure-erőforrások erőforrásnaplókat bocsátanak ki, és gazdag, gyakori adatokat szolgáltatnak az adott erőforrás működéséről. Ezek a naplók kérésenként vannak rögzítve, és "adatsík-naplóknak" is nevezik őket. Tekintse meg az Azure Monitor diagnosztikai beállításait az Azure-beli funkciók ajánlott áttekintéséhez. Ezeknek a naplóknak a tartalma erőforrástípusonként változik. Az Azure Cache for Redisben két lehetőség érhető el a naplózáshoz:
Az Azure Cache for Redis az Azure diagnosztikai beállításaival naplózza a gyorsítótár ügyfélkapcsolatainak adatait. A diagnosztikai beállítás naplózása és elemzése segít megérteni, hogy ki csatlakozik a gyorsítótárakhoz és a kapcsolatok időbélyegét. A naplóadatok felhasználhatók a biztonsági incidens hatókörének azonosítására és biztonsági naplózási célokra.
Különbségek az Azure Cache for Redis-szintek között
A kapcsolati naplók megvalósítása némileg eltér a szintek között:
Az alapszintű, a standard és a prémium szintű gyorsítótár ip-cím alapján kérdezi le az ügyfélkapcsolatokat, beleértve az egyes egyedi IP-címekről származó kapcsolatok számát is. Ezek a naplók nem kumulatívak. Az időponthoz kötött pillanatképeket jelölik, amelyek 10 másodperces időközönként készültek. A hitelesítési események (sikeres és sikertelen) és a leválasztási események nincsenek naplózva ezekben a szintekben.
A nagyvállalati és vállalati flash szintű gyorsítótárak a Redis Enterprise beépített naplózási kapcsolati események funkcióját használják. A naplózási kapcsolati események lehetővé teszik minden kapcsolat, leválasztási és hitelesítési esemény naplózását, beleértve a sikertelen hitelesítési eseményeket is.
A létrehozott kapcsolati naplók hasonlóak a szintek között, de vannak különbségek. A két formátum részletesebben is megjelenik a cikk későbbi részében.
Fontos
Az Alapszintű, a Standard és a Prémium szintű kapcsolatnaplózás a gyorsítótár aktuális ügyfélkapcsolatait kérdezi le . Ugyanazok az ügyfél IP-címek újra és újra megjelennek. Az Enterprise és az Enterprise Flash szinteken való naplózás az egyes kapcsolati eseményekre összpontosít. A naplók csak akkor fordulnak elő, ha a tényleges esemény először történt.
A Csatlakozás ion-naplózás előfeltételei/korlátozásai
Alapszintű, standard és prémium szintű szintek
Mivel ezekben a szintekben a kapcsolatnaplók 10 másodpercenként készített időponthoz kötött pillanatképekből állnak, a 10 másodperces időközök között létrehozott és eltávolított kapcsolatok nem lesznek naplózva.
A hitelesítési események nincsenek naplózva.
Az összes diagnosztikai beállítás akár 90 percet is igénybe vehet a kijelölt célhelyre való áramlás megkezdéséhez.
A kapcsolatnaplók engedélyezése kis teljesítménycsökkenést okozhat a gyorsítótárpéldányban.
Csak az Analytics-naplók díjszabási csomagja támogatott, ha naplókat streamel az Azure Log Analyticsbe. További információkért tekintse meg az Azure Monitor díjszabását.
Nagyvállalati és Vállalati Flash-szintek
Az OSS-fürtszabályzat használatakor a rendszer naplókat bocsát ki az egyes adatcsomópontokból. Vállalati fürtszabályzat használatakor csak a proxyként használt csomópont bocsát ki naplókat. Mindkét verzió továbbra is lefedi a gyorsítótárhoz való összes kapcsolatot. Ez csak egy architektúrabeli különbség.
Az adatvesztés (azaz a kapcsolati esemény hiánya) ritka, de lehetséges. Az adatvesztést általában hálózati problémák okozzák.
A leválasztási naplók még nem teljesen stabilak, és előfordulhat, hogy az események kimaradnak.
Mivel a vállalati szintek kapcsolatnaplói eseményalapúak, ügyeljen a megőrzési szabályzatokra. Ha például a megőrzés 10 napra van állítva, és egy 15 nappal ezelőtti kapcsolati esemény történt, előfordulhat, hogy a kapcsolat továbbra is létezik, de a kapcsolat naplója nem marad meg.
Ha aktív georeplikációs szolgáltatást használ, a naplózást egyenként kell konfigurálni a georeplikációs csoport egyes gyorsítótárpéldányaihoz.
Az összes diagnosztikai beállítás akár 90 percet is igénybe vehet a kijelölt célhelyre való áramlás megkezdéséhez.
A kapcsolatnaplók engedélyezése kis teljesítménycsökkenést okozhat a gyorsítótárpéldány számára.
Megjegyzés:
Az INFO vagy a CLIENT LIST parancsokkal mindig ellenőrizhető, hogy ki csatlakozik igény szerint egy gyorsítótárpéldányhoz.
Fontos
A naplók kiválasztásakor kiválaszthatja az adott kategória - vagy kategóriacsoportokat, amelyek előre definiált naplózási csoportok az Azure-szolgáltatásokban. Kategóriacsoportok használata esetén a továbbiakban nem konfigurálhatja a megőrzési beállításokat. Ha meg kell határoznia a kapcsolatnaplók megőrzési időtartamát, válassza inkább a Kategóriák szakaszban található elemet.
Naplócélok
Bekapcsolhatja az Azure Cache for Redis-példányok diagnosztikai beállításait, és erőforrásnaplókat küldhet a következő célhelyekre:
Log Analytics-munkaterület – nem kell ugyanabban a régióban lennie, mint a figyelt erőforrásnak.
Event Hub – A diagnosztikai beállítások nem férnek hozzá az eseményközpont erőforrásaihoz, ha a virtuális hálózatok engedélyezve vannak. Engedélyezze a megbízható Microsoft-szolgáltatások számára, hogy megkerülje ezt a tűzfalat? beállítást az eseményközpontokban, hogy hozzáférést biztosítson az eseményközpont erőforrásaihoz. Az eseményközpontnak ugyanabban a régióban kell lennie, mint a gyorsítótárnak.
Partnermegoldás – a lehetséges partnernaplózási megoldások listája itt található
A tárfiókok és az eseményközpontok használatáért normál adatátviteli díjakat kell fizetnie, amikor diagnosztikai naplókat küld mindkét célhelyre. A számlázás nem az Azure Cache for Redis, hanem az Azure Monitor alapján van kiszámlázva. Amikor naplókat küld a Log Analyticsnek, csak a Log Analytics-adatok betöltéséért kell fizetnie.
Lépjen az Azure Cache for Redis-fiókjához. Nyissa meg a Diagnosztikai beállítások panelt a bal oldali Figyelés szakasz alatt. Ezután válassza a Diagnosztikai beállítás hozzáadása lehetőséget.
A Diagnosztikai beállítások panelen válassza a Kategóriák Csatlakozás edClientList lehetőséget.
Lépjen az Azure Cache for Redis-fiókjához. Nyissa meg a Diagnosztikai Gépház – Naplózás panelt a bal oldali Figyelés szakasz alatt. Ezután válassza a Diagnosztikai beállítás hozzáadása lehetőséget.
A Diagnosztikai beállítás – Naplózás panelen válassza a kategóriákból Csatlakozás ioneseményeket.
Az Azure Monitor REST API használatával diagnosztikai beállításokat hozhat létre az interaktív konzolon keresztül. További információ: Létrehozás vagy frissítés.
Kérelem
PUT https://management.azure.com/{resourceUri}/providers/Microsoft.Insights/diagnosticSettings/{name}?api-version=2017-05-01-preview
Az Azure Monitor REST API használatával diagnosztikai beállításokat hozhat létre az interaktív konzolon keresztül. További információ: Létrehozás vagy frissítés.
Kérelem
PUT https://management.azure.com/{resourceUri}/providers/Microsoft.Insights/diagnosticSettings/{name}?api-version=2017-05-01-preview
az monitor diagnostic-settings create A paranccsal hozzon létre egy diagnosztikai beállítást az Azure CLI-vel. A parancs- és paraméterleírásokkal kapcsolatos további információkért lásd : Diagnosztikai beállítások létrehozása platformnaplók és metrikák különböző célhelyekre való küldéséhez. Ez a példa bemutatja, hogyan streamelhet adatokat négy különböző végpontra az Azure CLI használatával:
az monitor diagnostic-settings create A paranccsal hozzon létre egy diagnosztikai beállítást az Azure CLI-vel. A parancs- és paraméterleírásokkal kapcsolatos további információkért lásd : Diagnosztikai beállítások létrehozása platformnaplók és metrikák különböző célhelyekre való küldéséhez. Ez a példa bemutatja, hogyan streamelhet adatokat négy különböző végpontra az Azure CLI használatával:
Ezek a mezők és tulajdonságok a ConnectedClientList napló kategóriában jelennek meg. Az Azure Monitorban a rendszer a naplókat az ACRConnectedClientList erőforrás-szolgáltató neve alatt lévő táblában gyűjti MICROSOFT.CACHEössze.
Azure Storage-mező vagy tulajdonság
Azure Monitor Logs tulajdonság
Leírás
time
TimeGenerated
A napló utc-ben történő létrehozásának időbélyege.
location
Location
Az Azure Cache for Redis-példány helyének (régiójának) elérése.
category
n.a.
Elérhető naplókategóriák: ConnectedClientList.
resourceId
_ResourceId
Az Azure Cache for Redis-erőforrás, amelyhez engedélyezve vannak a naplók.
operationName
OperationName
A naplórekordhoz társított Redis-művelet.
properties
n.a.
A mező tartalmát az alábbi sorok ismertetik.
tenant
CacheName
Az Azure Cache for Redis-példány neve.
roleInstance
RoleInstance
Az ügyféllistát naplózó szerepkörpéldány.
connectedClients.ip
ClientIp
A Redis-ügyfél IP-címe.
connectedClients.privateLinkIpv6
PrivateLinkIpv6
A Redis-ügyfél privát kapcsolat IPv6-címe (ha van).
connectedClients.count
ClientCount
A társított IP-címről származó Redis-ügyfélkapcsolatok száma.
Minta tárfiók naplója
Ha a naplókat egy tárfiókba küldi, a naplók tartalma így néz ki.
Ezek a mezők és tulajdonságok a ConnectionEvents napló kategóriában jelennek meg. Az Azure Monitorban a rendszer a naplókat az REDConnectionEvents erőforrás-szolgáltató neve alatt lévő táblában gyűjti MICROSOFT.CACHEössze.
Azure Storage-mező vagy tulajdonság
Azure Monitor Logs tulajdonság
Leírás
time
TimeGenerated
Az eseménynapló rögzítésének időbélyege (UTC).
location
Location
Az Azure Cache for Redis-példány helyének (régiójának) elérése.
category
n.a.
Elérhető naplókategóriák: ConnectionEvents.
resourceId
_ResourceId
Az Azure Cache for Redis-erőforrás, amelyhez engedélyezve vannak a naplók.
operationName
OperationName
A naplórekordhoz társított Redis-művelet.
properties
n.a.
A mező tartalmát az alábbi sorok ismertetik.
eventEpochTime
EventEpochTime
A UNIX időbélyege (1970. január 1. óta eltelt másodpercek száma), amikor az esemény UTC-ben történt. Az időbélyeg a Log Analytics-munkaterület unixtime_seconds_todatetime függvényével konvertálható datetime formátumra.
clientIP
ClientIP
A Redis-ügyfél IP-címe. Az Azure Storage használata esetén az IP-cím A gyorsítótár típusa alapján IPv4 vagy privát kapcsolatÚ IPv6-formátum. A Log Analytics használata esetén az eredmény mindig az IPv4-ben jelenik meg, mivel egy külön IPv6-mező van megadva.
n.a.
PrivateLinkIPv6
A Redis-ügyfél privát kapcsolat IPv6-címe (csak a Private Link és a log analytics használata esetén jelenik meg).
id
ConnectionId
A Redis által hozzárendelt egyedi kapcsolatazonosító.
eventType
EventType
Kapcsolati esemény típusa (new_conn, hitelesítés vagy close_conn).
eventStatus
EventStatus
A hitelesítési kérelem eredménye állapotkódként (csak hitelesítési esemény esetén alkalmazható).
Megjegyzés:
Privát hivatkozás használata esetén a rendszer csak egy IPv6-címet naplóz (kivéve, ha az adatokat naplóelemzésre streameli). Az IPv6-címet az IPv6-cím utolsó négy bájtnyi adatának megtekintésével konvertálhatja egyenértékű IPv4-címgé. Az "fd40:8913:31:6810:6c31:200:a01:104" privát kapcsolat IPv6-címében például a hexadecimális utolsó négy bájtja a következő: "0a", "01", "01" és "04". (Vegye figyelembe, hogy az egyes kettőspont után a kezdő nullák ki vannak hagyva.) Ezek decimálisan "10", "1", "1" és "4" értéknek felelnek meg, így az IPv4-cím "10.1.1.4".
Minta tárfiók naplója
Ha a naplókat egy tárfiókba küldi, egy kapcsolati esemény naplója a következőképpen néz ki:
Az Azure Log Analytics használatával kapcsolatos oktatóanyagért tekintse meg a Log Analytics áttekintését az Azure Monitorban. Ne feledje, hogy akár 90 percig is eltarthat, amíg a naplók megjelennek a Log Analtyicsben.
Íme néhány alapszintű lekérdezés, amelyet modellként kell használni.
Az Azure Cache for Redis-ügyfélkapcsolatok óránként a megadott IP-címtartományon belül:
let IpRange = "10.1.1.0/24";
ACRConnectedClientList
// For particular datetime filtering, add '| where TimeGenerated between (StartTime .. EndTime)'
| where ipv4_is_in_range(ClientIp, IpRange)
| summarize ConnectionCount = sum(ClientCount) by TimeRange = bin(TimeGenerated, 1h)
A gyorsítótárhoz csatlakoztatott egyedi Redis-ügyfél IP-címek:
ACRConnectedClientList
| summarize count() by ClientIp
Az Azure Cache for Redis-kapcsolatok óránként a megadott IP-címtartományon belül:
REDConnectionEvents
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
| where EventType == "new_conn"
| summarize ConnectionCount = count() by TimeRange = bin(EventTime, 1h)
Az Azure Cache for Redis hitelesítési kérései óránként a megadott IP-címtartományon belül:
REDConnectionEvents
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| where EventType == "auth"
| summarize AuthencationRequestsCount = count() by TimeRange = bin(EventTime, 1h)
A gyorsítótárhoz csatlakoztatott egyedi Redis-ügyfél IP-címek:
REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0 AUTHENTICATION_FAILED - Invalid username and/or password.
// 1 AUTHENTICATION_FAILED_TOO_LONG - Username or password are too long.
// 2 AUTHENTICATION_NOT_REQUIRED - Client tried to authenticate, but authentication isn’t necessary.
// 3 AUTHENTICATION_DIRECTORY_PENDING - Attempting to receive authentication info from the directory in async mode.
// 4 AUTHENTICATION_DIRECTORY_ERROR - Authentication attempt failed because there was a directory connection error.
// 5 AUTHENTICATION_SYNCER_IN_PROGRESS - Syncer SASL handshake. Return SASL response and wait for the next request.
// 6 AUTHENTICATION_SYNCER_FAILED - Syncer SASL handshake. Returned SASL response and closed the connection.
// 7 AUTHENTICATION_SYNCER_OK - Syncer authenticated. Returned SASL response.
// 8 AUTHENTICATION_OK - Client successfully authenticated.
| where EventType == "auth" and EventStatus == 2 or EventStatus == 8 or EventStatus == 7
| summarize count() by ClientIp
Sikertelen hitelesítési kísérletek a gyorsítótárba
REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0 AUTHENTICATION_FAILED - Invalid username and/or password.
// 1 AUTHENTICATION_FAILED_TOO_LONG - Username or password are too long.
// 2 AUTHENTICATION_NOT_REQUIRED - Client tried to authenticate, but authentication isn’t necessary.
// 3 AUTHENTICATION_DIRECTORY_PENDING - Attempting to receive authentication info from the directory in async mode.
// 4 AUTHENTICATION_DIRECTORY_ERROR - Authentication attempt failed because there was a directory connection error.
// 5 AUTHENTICATION_SYNCER_IN_PROGRESS - Syncer SASL handshake. Return SASL response and wait for the next request.
// 6 AUTHENTICATION_SYNCER_FAILED - Syncer SASL handshake. Returned SASL response and closed the connection.
// 7 AUTHENTICATION_SYNCER_OK - Syncer authenticated. Returned SASL response.
// 8 AUTHENTICATION_OK - Client successfully authenticated.
| where EventType == "auth" and EventStatus != 2 and EventStatus != 8 and EventStatus != 7
| project ClientIp, EventStatus, ConnectionId
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: