У нас есть куча метрик Azure, которые регистрируют метрики в зависимости от контекста выполнения ... кажется, что вы не можете сделать это, используя OOTB TraceWriter
или ILogger
(по крайней мере, в том, что я видел) поскольку нет эквивалента тому, что, как я предполагаю, будет называться log.LogEvent()
..
Итак ... этот URL (https://docs.microsoft.com/en-us/azure/azure-functions/functions-monitoring#custom-telemetry-in-c-functions) показывает схему для использования TelemetryClient()
внутри AzureФункция, позволяющая сделать то же самое, с примерами для перехода на EventTelemetry()
и т. Д., Однако, чтобы убедиться, что корреляция работает, вы должны установить контекст для каждой записываемой вещи:
var evt = new EventTelemetry("Function called");
evt.Context.Operation.Id = executionContext.InvocationId.ToString();
telemetryClient.TrackEvent(evt);
Все это кажется довольно логичнымза исключением того, что у меня есть общий класс (TelemetryManager
), который помогает создавать TelemetryClient()
- так что нам не нужно повторять код в каждой отдельной функции, которая просто сообщает клиенту серию дополнительных настроек ... этотакже реализует интерфейс ведения журнала ITelemetry
, чтобы у нас был позже интерфейс для модульного тестирования, и вы можете выполнить .. (здесь для простоты используется трассировка):
static CustomTelemetryManager logger = new CustomTelemetryManager();
logger.Trace($"thing i want to trace: {x.value}");
logger.Trace()
метод просто делает этовызовите метод telemetryClient.TrackTrace()
вCustomTelemetryManager()
class - некоторые другие методы более сложны.
В любом случае, интерфейс есть, поэтому при модульном тестировании мы можем просто сделать:
// gets all the app insights key, and sets various other properties.
static DebugLogger logger = new DebugLogger();
logger.Trace($"thing i want to trace: {x.value}");
и он будет просто Debug.WriteLine()
вместо того, чтобы пытаться вызвать AI
Вопрос 1 : существует ли «лучший» способ обмена кодом Application Insights для модульных тестов, поскольку это единственная причина, по которой мы имеем этоITelemetry
интерфейс вообще ... чтобы облегчить фиктивный регистратор для модульных тестов.
В конечном счете, все, что мне нужно сделать, это дать telemetryClient.TrackTrace()
контекст выполняемого вызова, иединственный способ сделать это прямо сейчас, похожий на код события дорожки, приведенный выше ..
var trace = new TraceTelemetry($"i am a trace.");
trace.Context.Operation.Id = context.InvocationId.ToString();
logger.Trace(trace);
Поскольку TelemetryClient
является общим для всех функций, мне нужно применить контекст кМетрика непосредственно перед отправкой в журнал ..
Вопрос 2 : Это единственный способ, которым я могу это сделать .. что-то вроде:
public void TrackTrace(string msg, ExecutionContext ctx)
{
var trace = new TraceTelemetry(msg);
trace.Context.Operation.Id = ctx.InvocationId.ToString();
client.TrackTrace(trace);
}
Как это будет означатьизменение интерфейса, а затем также означает, что для модульного тестированияХолл также должен предоставить какой-то фиктивный контекст для регистратора отладки, который кажется немного неуклюжимне вижу дрова для деревьев!