Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi
Apigee Edge'in MessageLogging politikası, API proxy'si geliştiricilerinin syslog'a veya diske (yalnızca Private Cloud için Edge) özel mesajlar kaydetmesine olanak tanır. Giriş parametreleri, istek yükü, yanıt kodu, hata mesajları (varsa) vb. gibi API isteğiyle ilgili tüm önemli bilgiler daha sonra başvurmak veya hata ayıklamak için günlüğe kaydedilebilir. Politika, günlük kaydını gerçekleştirmek için arka plan işlemi kullanırken politikayı kullanmayla ilgili uyarılar vardır.
Antipattern
MessageLogging politikası, bir API isteği hakkında daha fazla bilgi edinmek ve API isteğiyle ilgili karşılaşılan sorunları ayıklamak için etkili bir yöntem sunar. Ancak aynı MessageLogging politikasını birden fazla kez kullanmak veya birden fazla MessageLogging politikasının PostClientFlow dışındaki akışlarda aynı API proxy'sinde verileri parçalar halinde kaydetmesi olumsuz sonuçlar doğurabilir. Bunun nedeni, Apigee Edge'in MessageLogging politikası için harici bir syslog sunucusuna bağlantı açmasıdır. Politika, TCP üzerinden TLS kullanıyorsa TLS bağlantısı oluşturmak için ek yük gerekir.
Bunu bir örnek API proxy'si yardımıyla açıklayalım.
API proxy'si
Aşağıdaki örnekte, "LogRequestInfo" adlı bir MessageLogging politikası İstek akışına yerleştirilir ve "LogResponseInfo" adlı başka bir MessageLogging politikası Yanıt akışına eklenir. Her ikisi de ProxyEndpoint PreFlow'da bulunur. LogRequestInfo politikası, API proxy'si isteği alır almaz arka planda yürütülür. LogResponseInfo politikası ise proxy, hedef sunucudan yanıt aldıktan sonra ancak yanıtı API istemcisine döndürmeden önce yürütülür. Bu durumda iki TLS bağlantısı kurulabileceğinden ek sistem kaynakları tüketilir.
Ayrıca, yalnızca API proxy'si yürütülürken bir hata oluşursa yürütülen "LogErrorInfo" adlı bir MessageLogging politikası da vardır.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
...
<FaultRules>
<FaultRule name="fault-logging">
<Step>
<Name>LogErrorInfo</Name>
</Step>
</FaultRule>
</FaultRules>
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>LogRequestInfo</Name>
</Step>
</Request>
</PreFlow>
<PreFlow name="PreFlow">
<Response>
<Step>
<Name>LogResponseInfo</Name>
</Step>
</Response>
</PreFlow>
...
</ProxyEndpoint>İleti Günlüğe Kaydetme Politikası
Aşağıdaki örnek politika yapılandırmalarında, veriler TCP üzerinden TLS kullanılarak üçüncü taraf günlük sunucularına kaydedilmektedir. Bu politikalardan birden fazlası aynı API proxy'sinde kullanılıyorsa TLS bağlantılarını oluşturma ve yönetme ek yükü, ek sistem belleği ve CPU döngülerini işgal ederek büyük ölçekte performans sorunlarına yol açar.
LogRequestInfo politikası
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogRequestInfo">
<Syslog>
<Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {request.queryparam.w}.</Message>
<Host>logs-01.loggly.com</Host>
<Port>6514</Port>
<Protocol>TCP</Protocol>
<FormatMessage>true</FormatMessage>
<SSLInfo>
<Enabled>true</Enabled>
</SSLInfo>
</Syslog>
<logLevel>INFO</logLevel>
</MessageLogging>LogResponseInfo politikası
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogResponseInfo">
<Syslog>
<Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Status: {response.status.code}, Response {response.content}.</Message>
<Host>logs-01.loggly.com</Host>
<Port>6514</Port>
<Protocol>TCP</Protocol>
<FormatMessage>true</FormatMessage>
<SSLInfo>
<Enabled>true</Enabled>
</SSLInfo>
</Syslog>
<logLevel>INFO</logLevel>
</MessageLogging>LogErrorInfo politikası
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogErrorInfo">
<Syslog>
<Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Fault name: {fault.name}.</Message>
<Host>logs-01.loggly.com</Host>
<Port>6514</Port>
<Protocol>TCP</Protocol>
<FormatMessage>true</FormatMessage>
<SSLInfo>
<Enabled>true</Enabled>
</SSLInfo>
</Syslog>
<logLevel>ERROR</logLevel>
</MessageLogging>Etki
- API Proxy akışı sırasında günlük sunucularıyla birden çok kez bağlantı kurulması nedeniyle ağ iletişimi ek yükünün artması.
- Syslog sunucusu yavaşsa veya birden fazla syslog çağrısının neden olduğu yüksek hacmi işleyemiyorsa ileti işlemcisinde geri basınç oluşur. Bu durum, istek işlemenin yavaşlamasına ve potansiyel olarak yüksek gecikmeye veya 504 Gateway Timeout hatalarına neden olur.
- Dosya günlüğünün kullanıldığı özel bulut kurulumlarında ileti işlemcisi tarafından açılan eşzamanlı dosya tanımlayıcılarının sayısının artması.
MessageLogging politikası PostClient akışı dışındaki akışlara yerleştirilirse bu politikanın yürütülmesinden önce herhangi bir hata oluşması durumunda MessageLogging politikası yürütülmeyeceğinden bilgilerin kaydedilmemesi söz konusu olabilir.
Önceki ProxyEndpoint örneğinde, bilgiler aşağıdaki durumlarda kaydedilmez:
- İstek akışında LogRequestInfo politikasından önce yer alan politikalardan herhangi biri başarısız olursa.
veya - Hedef sunucu herhangi bir hatayla (HTTP 4XX, 5XX) başarısız olursa. Bu durumda, başarılı bir yanıt döndürülmediğinde LogResponseInfo politikası yürütülmez.
Her iki durumda da LogErrorInfo politikası yürütülür ve yalnızca hatayla ilgili bilgiler günlüğe kaydedilir.
- İstek akışında LogRequestInfo politikasından önce yer alan politikalardan herhangi biri başarısız olursa.
En iyi uygulama
- Günlüğe kaydedilecek tüm akış değişkenlerini ayarlamak için ExtractVariables politikası veya JavaScript politikası kullanın. Böylece bu değişkenler MessageLogging politikası için kullanılabilir hale gelir.
- Koşulsuz olarak yürütülen PostClientFlow'da gerekli tüm verileri kaydetmek için tek bir MessageLogging politikası kullanın.
- Syslog sunucusuna iletilerin teslimatının garanti edilmesinin gerekmediği ve TLS/SSL'nin zorunlu olmadığı UDP protokolünü kullanın.
MessageLogging politikası, hata işleme dahil olmak üzere gerçek API işlevlerinden bağımsız olacak şekilde tasarlanmıştır. Bu nedenle, istek/yanıt işleme dışında olan PostClientFlow'da çağrılması, API'nin başarısız olup olmamasından bağımsız olarak her zaman veri kaydedeceği anlamına gelir.
Aşağıda, PostClientFlow'da MessageLogging politikasının çağrılmasına ilişkin bir örnek verilmiştir:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...
<PostClientFlow>
<Request/>
<Response>
<Step>
<Name>LogInfo</Name>
</Step>
</Response>
</PostClientFlow>
...Aşağıda, tüm verileri günlüğe kaydeden LogInfo adlı bir MessageLogging politikası örneği verilmiştir:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging name="LogInfo">
<Syslog>
<Message>[3f509b58 tag="{organization.name}.{apiproxy.name}.{environment.name}"] Weather request for WOEID {woeid} Status: {weather.response.code}, Response {weather.response}, Fault: {fault.name:None}.</Message>
<Host>logs-01.loggly.com</Host>
<Port>6514</Port>
<Protocol>TCP</Protocol>
<FormatMessage>true</FormatMessage>
<SSLInfo>
<Enabled>true</Enabled>
</SSLInfo>
</Syslog>
<logLevel>INFO</logLevel>
</MessageLogging>Hata akışından sonra PostClientFlow'da yanıt değişkenleri kullanılamadığından woeid ve weather.response* değişkenlerini ExtractVariables veya JavaScript politikalarını kullanarak açıkça ayarlamak önemlidir.
Daha fazla bilgi
- JavaScript politikası
- ExtractVariables politikası
- Hatalar oluştuğunda dahil olmak üzere, proxy işleme işleminden sonra kodun yürütülmesini sağlama (PostClientFlow ile)