基于 Application Insights 与 OpenTelemetry 构建 MCP Server 生产级监控与可观测性

教程文档人工智能【免费下载链接】mcp-for-beginnersThis open-source curriculum introduces the fundamentals of Model Context Protocol (MCP) through real-world, cross-language examples in .NET, Java, TypeScript, JavaScript, Rust and Python. Designed for developers, it focuses on practical techniques for building modular, scalable, and secure AI workflows from session setup to service orchestration.项目地址https://gitcode.com/GitHub_Trending/mc/mcp-for-beginners点击查看免费下载导读本文是 mcp-for-beginners 仓库中11-MCPServerHandsOnLabs系列实战课程的第 11 个 LabMonitoring and Observability的完整技术指南。它以 Zava Retail Analytics MCP Server 为落地场景系统讲解如何为生产环境的 MCP 服务器实现监控与可观测性包括 Application Insights 集成、结构化日志、自定义指标采集、智能告警、运营 Dashboard 以及故障排查 Runbook。读完本文你将掌握一套从裸遥测数据到可执行运维洞察的完整生产级监控方案。学习目标与前置上下文本 Lab 属于 MCP Server with PostgreSQL - Complete Learning Guide 的第 11 站紧接 Lab 10: Deployment Strategies 之后。在开始前你应该已经完成 Lab 05: MCP Server Implementation拥有一个基于 FastMCP 的 MCP 服务器并具备/health、/health/detailed、/health/ready健康检查端点见 health_check.py 实现。在 Lab 03: Environment Setup 中配置好.env其中包含APPLICATIONINSIGHTS_CONNECTION_STRING等遥测连接配置。完成本 Lab 后你将能够实现MCP Server 的 Application Insights 全面集成设计支持高效故障排查的结构化日志模式创建性能指标采集与分析系统配置带可操作通知的智能告警构建用于实时监控的运营 Dashboard建立有效的故障排查流程与 Runbook。可观测性三支柱指标、日志、追踪在进入具体实现前需要建立对可观测性Observability三支柱的共识。有效的生产监控必须同时覆盖支柱回答的问题本文对应实现指标Metrics系统现在处于什么状态MetricsCollector自定义指标 OpenTelemetry Meter日志Logs系统发生了什么事StructuredFormatterMCPLogger结构化 JSON 日志追踪Traces一次请求端到端走了哪些路径OpenTelemetry Tracer trace_operation上下文管理器本 Lab 的目标正是把三支柱整合进 MCP Server将原始遥测数据转化为能够理解系统行为、优化性能、保障高可用性的可执行洞察。Application Insights 集成初始化遥测管理Application Insights 是 Azure Monitor 的应用性能监控服务。在 MCP Server 中我们通过azure.monitor.opentelemetry提供的configure_azure_monitor把它与 OpenTelemetry 标准衔接起来。核心封装类MCPTelemetryManager源码见 monitoring.py负责整个生命周期class MCPTelemetryManager: Comprehensive telemetry management for MCP server. def __init__(self, connection_string: str): self.connection_string connection_string self.tracer None self.meter None self.custom_metrics {} def initialize_telemetry(self, app): Initialize Application Insights and OpenTelemetry. # Configure Azure Monitor configure_azure_monitor( connection_stringself.connection_string, logger_namemcp_server, disable_offline_storageFalse ) # Get tracer and meter self.tracer trace.get_tracer(__name__) self.meter metrics.get_meter(__name__) # Initialize custom metrics self._setup_custom_metrics() # Instrument FastAPI FastAPIInstrumentor.instrument_app(app) # Instrument database AsyncPGInstrumentor().instrument() # Instrument HTTP requests RequestsInstrumentor().instrument() logging.info(Telemetry initialization complete)各配置参数与自动插桩Auto-Instrumentation的作用如下配置 / 调用作用说明connection_stringApplication Insights 资源连接字符串格式为InstrumentationKeyyour-key;...来源于.env中的APPLICATIONINSIGHTS_CONNECTION_STRINGlogger_namemcp_server指定日志器名称使日志关联到 MCP Server 组件便于筛选disable_offline_storageFalse保留离线存储网络不可达时数据本地暂存恢复后补传避免遥测丢失FastAPIInstrumentor.instrument_app(app)HTTP 层自动追踪每个 MCP 请求自动生成 Trace 与请求指标AsyncPGInstrumentor().instrument()数据库层自动追踪捕获 asyncpg 查询的时序与调用关系RequestsInstrumentor().instrument()出站 HTTP 自动追踪记录 MCP Server 对外部服务如 Azure AI的调用MCPTelemetryManager在模块底部以全局单例形式实例化连接字符串直接读取服务端配置telemetry_manager MCPTelemetryManager( connection_stringconfig.server.applicationinsights_connection_string )注册自定义业务指标除自动插桩外_setup_custom_metrics通过 OpenTelemetry Meter 创建了覆盖请求、数据库、工具、系统与错误五个维度的自定义指标它们正是后续 Dashboard 和告警的数据来源指标名称类型语义mcp_requests_totalCounterMCP 请求总数mcp_request_duration_secondsHistogramMCP 请求耗时秒database_queries_totalCounter数据库查询总数database_query_duration_secondsHistogram数据库查询耗时秒database_connections_activeUpDownCounter当前活跃数据库连接数tool_executions_totalCounterMCP 工具执行总数tool_execution_duration_secondsHistogram工具执行耗时秒system_cpu_usage_percentGaugeCPU 使用率百分比system_memory_usage_bytesGauge内存使用量字节errors_totalCounter错误总数指标类型的选择是有讲究的Counter只增不减适合计数类请求量、错误量Histogram适合分布类耗时可进一步计算 P95/P99UpDownCounter可增减适合连接池这类瞬时水位Gauge适合 CPU、内存这类瞬时快照。用追踪上下文自动关联指标trace_operation是一个上下文管理器它把分布式追踪Span与指标采集绑定在一起进入操作时启动 Span 并写入属性成功时按操作名自动累加对应指标失败时记录异常、设置错误状态并累加errors_totalcontextmanager def trace_operation(self, operation_name: str, attributes: Dict[str, Any] None): Create a traced operation with automatic metrics collection. with self.tracer.start_as_current_span(operation_name) as span: start_time time.time() # Add attributes to span if attributes: for key, value in attributes.items(): span.set_attribute(key, value) try: yield span # Record success metrics duration time.time() - start_time if request in operation_name.lower(): self.custom_metrics[mcp_requests_total].add(1, {status: success}) self.custom_metrics[mcp_request_duration].record(duration) elif query in operation_name.lower(): self.custom_metrics[database_queries_total].add(1, {status: success}) self.custom_metrics[database_query_duration].record(duration) elif tool in operation_name.lower(): self.custom_metrics[tool_executions_total].add(1, {status: success}) self.custom_metrics[tool_execution_duration].record(duration) except Exception as e: # Record error span.record_exception(e) span.set_status(trace.Status(trace.StatusCode.ERROR, str(e))) # Record error metrics self.custom_metrics[errors_total].add(1, { operation: operation_name, error_type: type(e).__name__ }) raise这里的关键设计是按操作名约定自动分类打点命名中包含request、query、tool的操作会各自命中对应的指标分支无需在每个业务方法里手动编写指标代码从而保持业务代码整洁。系统级指标采集record_system_metrics使用psutil周期性采集主机资源并将数据库连接池水位写入指标def record_system_metrics(self): Record system-level metrics. # CPU usage cpu_percent psutil.cpu_percent(interval1) self.custom_metrics[system_cpu_usage].set(cpu_percent) # Memory usage memory psutil.virtual_memory() self.custom_metrics[system_memory_usage].set(memory.used) # Database connections (if available) if hasattr(db_provider, connection_pool) and db_provider.connection_pool: active_connections db_provider.connection_pool.get_size() self.custom_metrics[database_connections_active].add(active_connections)这与 Lab 10 部署篇中的PerformanceMonitor思路一致后者以 30 秒为周期循环采集 CPU、内存、请求速率、错误率等指标并对 CPU 90%、内存 90%、错误率 5% 发出 warning 日志。二者互为印证监控指标应同时覆盖进程内MCP 请求/工具与进程外主机资源、数据库两个层面。结构化日志与增强日志工具JSON 结构化格式化器生产环境的海量日志必须可机器解析、可检索。StructuredFormatter继承标准库logging.Formatter把每条日志序列化为带时间戳、级别、模块、函数名、行号的 JSON 对象class StructuredFormatter(logging.Formatter): Custom formatter for structured JSON logging. def format(self, record: logging.LogRecord) - str: Format log record as structured JSON. # Base log structure log_entry { timestamp: datetime.utcnow().isoformat() Z, level: record.levelname, logger: record.name, message: record.getMessage(), module: record.module, function: record.funcName, line: record.lineno } # Add exception information if present if record.exc_info: log_entry[exception] { type: record.exc_info[0].__name__, message: str(record.exc_info[1]), traceback: traceback.format_exception(*record.exc_info) } # Add custom attributes from extra if hasattr(record, extra_data): log_entry.update(record.extra_data) # Add correlation ID if available if hasattr(record, correlation_id): log_entry[correlation_id] record.correlation_id # Add user context if available if hasattr(record, user_id): log_entry[user_id] record.user_id if hasattr(record, rls_user_id): log_entry[rls_user_id] record.rls_user_id return json.dumps(log_entry, ensure_asciiFalse)该格式化器支持三类上下文增强是实现可关联、可定位日志的关键异常上下文record.exc_info存在时输出异常类型、消息与完整 traceback业务上下文extra_data通过logging的extra参数注入任意结构化字段身份与关联上下文correlation_id跨请求关联、user_id/rls_user_id用户与行级安全上下文对应本系列 Lab 02 的 RLS 多租户设计。MCPLogger面向 MCP 场景的日志门面MCPLogger封装了结构化日志的初始化并在其上提供四类业务语义日志方法方法事件类型典型字段说明log_mcp_requestmcp_requestmethod、user_id、rls_user_id、status、duration_msMCP 方法级请求日志log_database_querydatabase_queryquery_hash、duration_ms、row_count、query_preview数据库查询性能日志耗时超过 1 秒自动升级为 WARNING 级别便于快速定位慢查询log_security_eventsecurity_eventsecurity_event_type、ip_address、success安全事件日志失败事件以 WARNING 记录log_performance_metricperformance_metricmetric_name、value、unit、dimensions自定义性能指标日志def log_database_query( self, query: str, duration: float, row_count: int None, user_id: str None, **kwargs ): Log database query with performance data. extra_data { event_type: database_query, query_hash: hash(query.strip()), duration_ms: duration * 1000, query_preview: query[:100] ... if len(query) 100 else query } if row_count is not None: extra_data[row_count] row_count if user_id: extra_data[user_id] user_id extra_data.update(kwargs) level logging.WARNING if duration 1.0 else logging.INFO self.logger.log( level, fDatabase query executed ({duration*1000:.2f}ms), extra{extra_data: extra_data} )注意几个值得在生产复用的细节query_hash用于聚合同类查询而避免暴露完整 SQLquery_preview截断到 100 字符兼顾可读性与隐私动态级别调整让慢查询天然成为排查焦点。模块底部同样导出全局单例mcp_logger MCPLogger(mcp_server)全应用共享同一日志通道。自定义指标采集与聚合分析结构化日志解决发生了什么而MetricsCollector负责把业务指标沉淀为可统计、可聚合的数据。它用deque(maxlen1000)做环形缓冲并支持留存期清理dataclass class MetricPoint: Individual metric data point. timestamp: float value: float dimensions: Dict[str, str] class MetricsCollector: Advanced metrics collection and analysis. def __init__(self, retention_minutes: int 60): self.retention_seconds retention_minutes * 60 self.metrics_buffer defaultdict(lambda: deque(maxlen1000)) self.aggregated_metrics {} def record_metric( self, name: str, value: float, dimensions: Dict[str, str] None ): Record a metric point. metric_point MetricPoint( timestamptime.time(), valuevalue, dimensionsdimensions or {} ) self.metrics_buffer[name].append(metric_point) self._cleanup_old_metrics(name)get_metric_summary提供带时间窗口的统计摘要一次性输出 count、min、max、mean、median 以及p95 / p99 百分位def get_metric_summary( self, name: str, time_window_minutes: int 5 ) - Dict[str, Any]: Get statistical summary of a metric. time_window_seconds time_window_minutes * 60 cutoff_time time.time() - time_window_seconds relevant_points [ point for point in self.metrics_buffer[name] if point.timestamp cutoff_time ] if not relevant_points: return {error: No data available} values [point.value for point in relevant_points] return { count: len(values), min: min(values), max: max(values), mean: statistics.mean(values), median: statistics.median(values), p95: self._percentile(values, 95), p99: self._percentile(values, 99), time_window_minutes: time_window_minutes }p95/p99 之所以关键是因为 MCP 服务的尾部延迟往往最能代表真实用户体验。均值会掩盖慢请求而百分位能暴露 5% 或 1% 的最慢请求是否恶化。collect_business_metrics则把指标采集延伸到业务洞察按查询类型business_queries_by_type、门店活跃度user_activity_by_store如 seattle/redmond/bellevue/online、工具使用量tool_usage如execute_sales_query、semantic_search_products打点。这些维度直接服务于零售场景的运营决策说明监控不只是 IT 指标还应包含业务语义指标。智能告警系统告警规则模型告警是监控闭环的出口。AlertManager采用规则驱动设计AlertRule由条件函数、严重级别、冷却期和消息模板构成Alert是规则触发后的具体实例dataclass class AlertRule: Alert rule configuration. name: str condition: Callable[[Dict[str, Any]], bool] severity: AlertSeverity cooldown_minutes: int message_template: str enabled: bool True dataclass class Alert: Alert instance. rule_name: str severity: AlertSeverity message: str timestamp: float details: Dict[str, Any] acknowledged: bool False严重级别枚举定义了LOW / MEDIUM / HIGH / CRITICAL四级与后续通知渠道的颜色映射一一对应。内置默认规则与阈值_setup_default_rules注册了六个开箱即用的告警规则其阈值是生产监控的常见起点规则名触发条件严重级别冷却期说明database_connection_failuredatabase_status ! healthyCRITICAL5 分钟数据库不可用服务可能中断high_error_rate错误率 5%HIGH10 分钟错误率异常升高slow_query_performance平均查询耗时 2 秒MEDIUM15 分钟慢查询性能问题high_cpu_usageCPU 85%MEDIUM10 分钟CPU 资源压力high_memory_usage内存占用 90%HIGH5 分钟内存资源压力authentication_failures认证失败率 10%HIGH5 分钟疑似安全事件规则通过 lambda 条件函数与指标字典解耦例如# High error rate self.add_alert_rule(AlertRule( namehigh_error_rate, conditionlambda metrics: metrics.get(error_rate, 0) 0.05, # 5% error rate severityAlertSeverity.HIGH, cooldown_minutes10, message_templateHigh error rate detected: {error_rate:.2%}. Investigate immediately. ))消息模板支持str.format风格的指标占位符如{error_rate:.2%}在触发时用实际指标值填充确保告警信息即点即用。评估、触发与冷却机制evaluate_metrics是告警引擎的核心入口遍历所有启用的规则条件满足则触发、条件恢复则解除async def evaluate_metrics(self, metrics: Dict[str, Any]): Evaluate metrics against alert rules. for rule_name, rule in self.alert_rules.items(): if not rule.enabled: continue try: # Check if rule condition is met if rule.condition(metrics): await self._trigger_alert(rule, metrics) else: # Clear alert if condition no longer met await self._clear_alert(rule_name) except Exception as e: mcp_logger.logger.error(fError evaluating alert rule {rule_name}: {e})_trigger_alert中值得注意的两点设计冷却期Cooldown同一规则在上次触发后的冷却期内不再重复触发避免告警风暴Alert Fatigue。例如数据库连接失败的冷却期为 5 分钟即最多每 5 分钟告警一次。解除通知Resolution Notification当 HIGH / CRITICAL 级告警解除时会生成一条RESOLVED:前缀、LOW 级别的解除通知让值班人员确认问题已恢复形成完整的触发—处理—解除闭环。多渠道通知_setup_notification_channels从环境变量读取凭据并按需启用通道配置了 SMTP 账号才启用邮件配置了TEAMS_WEBHOOK_URL才启用 Teams配置了SLACK_WEBHOOK_URL才启用 Slack# Email notifications email_config { smtp_server: os.getenv(SMTP_SERVER, smtp.office365.com), smtp_port: int(os.getenv(SMTP_PORT, 587)), username: os.getenv(SMTP_USERNAME), password: os.getenv(SMTP_PASSWORD), from_address: os.getenv(ALERT_FROM_EMAIL), to_addresses: os.getenv(ALERT_TO_EMAILS, ).split(,) } if email_config[username] and email_config[password]: self.notification_channels[email] EmailNotifier(email_config) # Microsoft Teams webhook teams_webhook os.getenv(TEAMS_WEBHOOK_URL) if teams_webhook: self.notification_channels[teams] TeamsNotifier(teams_webhook)发送采用异步并发_send_notifications为每个通道创建asyncio.create_task并用asyncio.wait_for(..., timeout30.0)限制总等待时间超时仅记录 warning保证通知失败不会阻塞主告警流程。三个通知器各有特色EmailNotifierSMTP STARTTLS正文包含规则、级别、时间与完整指标 JSON 明细TeamsNotifier发送 MessageCard主题色随严重级别变化LOW 绿色 / MEDIUM 黄色 / HIGH 橙色 / CRITICAL 红色以facts呈现时间戳与级别SlackNotifier同 webhook 模式SLACK_WEBHOOK_URL。告警触发的同时还会调用mcp_logger.log_security_event(alert_triggered, ...)把告警本身作为安全事件落入日志便于事后审计。运营 Dashboard 构建Azure Monitor WorkbooksApplication Insights 的 Workbooks 支持用 KQL 查询把遥测数据可视化为交互式仪表盘。本 Lab 提供的 Workbook JSON 模板见 11-Monitoring/README.md包含四个核心图表1. MCP 请求量与性能时间图requests | where timestamp ago(1h) | where name contains mcp | summarize RequestCount count(), AvgDuration avg(duration) by bin(timestamp, 5m) | order by timestamp asc以 5 分钟为粒度聚合近 1 小时的 MCP 请求数与平均耗时直接反映服务吞吐与响应健康度。2. 数据库查询性能时间图含百分位customMetrics | where name database_query_duration_seconds | where timestamp ago(1h) | summarize AvgDuration avg(value), P95Duration percentile(value, 95), P99Duration percentile(value, 99) by bin(timestamp, 5m) | order by timestamp asc针对前文注册的database_query_duration_seconds指标同时输出均值、P95、P99 三条曲线——这是判断数据库是否存在尾部延迟风险的标准视图。3. 错误率分析柱状图24 小时exceptions | where timestamp ago(24h) | where method contains mcp | summarize ErrorCount count() by bin(timestamp, 1h), type | order by timestamp asc按小时与异常类型聚合 24 小时内的 MCP 异常用于发现错误突增的时间段与错误类别分布。4. 系统资源使用折线图customMetrics | where name in (system_cpu_usage_percent, system_memory_usage_bytes) | where timestamp ago(2h) | extend MetricType case( name system_cpu_usage_percent, CPU %, name system_memory_usage_bytes, Memory GB, Unknown ) | extend NormalizedValue case( name system_memory_usage_bytes, value / (1024*1024*1024), value ) | summarize AvgValue avg(NormalizedValue) by bin(timestamp, 5m), MetricType | order by timestamp asc将内存字节归一化为 GB 后与 CPU 百分比同图对比直观呈现资源水位。Workbook 的fallbackResourceIds占位符{subscription-id}、{resource-group}、{app-insights-name}需要在导入时替换为实际资源。自建 Dashboard API除 Azure 内置 Workbook 外DashboardDataProvider直接以 FastAPI 路由暴露监控数据前缀/dashboard四个端点覆盖运营全貌端点返回内容GET /dashboard/overview活跃告警数、关键告警数、近 1 小时请求数、平均响应时间、错误率、数据库状态、系统健康GET /dashboard/performance?hours24逐小时时间序列请求量、平均耗时、错误数、CPU、内存GET /dashboard/business热门查询、门店活跃度、工具使用统计、用户模式、高峰时段GET /dashboard/alerts当前活跃告警列表规则名、级别、消息、时间戳、确认状态其实现复用了前面两层的成果——metrics_collector提供统计摘要alert_manager提供告警状态async def get_overview_metrics(self) - Dict[str, Any]: Get high-level overview metrics. current_time time.time() one_hour_ago current_time - 3600 return { timestamp: current_time, active_alerts: len(self.alert_manager.active_alerts), critical_alerts: len([ alert for alert in self.alert_manager.active_alerts.values() if alert.severity AlertSeverity.CRITICAL ]), requests_last_hour: await self._get_request_count(one_hour_ago), avg_response_time: await self._get_avg_response_time(one_hour_ago), error_rate: await self._get_error_rate(one_hour_ago), database_status: await self._get_database_status(), system_health: await self._get_system_health() }错误率的计算逻辑值得单独强调error_count / total_requests当总请求数为 0 时返回 0.0避免除零。这类 Dashboard 即可以作为内部监控页面也可以被外部监控系统如 Prometheus 抓取 / 巡检机器人消费与 Lab 12 中的OperationalHealth.comprehensive_health_check()相互补充——后者以组件化健康报告 失败即告警的思路覆盖数据库、AI 服务、系统资源与应用四个维度。故障排查自动化诊断与运营 Runbook自动化诊断引擎DiagnosticsEngine把运维经验固化为可重复执行的检查清单。每个检查返回结构化的DiagnosticResultcheck_name / status / message / details / remediation状态分为pass、fail、warning三档dataclass class DiagnosticResult: Result of a diagnostic check. check_name: str status: str # pass, fail, warning message: str details: Dict[str, Any] remediation: Optional[str] None默认注册八个检查项检查关注点判定示例_check_database_connectivity数据库连通性与响应响应 1 秒 → warning不健康 → fail_check_azure_servicesAzure AI 服务配置有效性未配置项目/OpenAI 端点 → fail_check_system_resourcesCPU / 内存 / 磁盘水位任一 85% → warning 并给出缩放建议_check_configuration必需环境变量与配置一致性如健康检查开启但未配置 Application Insights→ fail_check_network_connectivity网络可达性见注册列表_check_disk_space磁盘空间见注册列表_check_log_files日志文件状态见注册列表_check_security_status安全状态见注册列表run_full_diagnostics逐个执行并捕获异常任何一项抛错都会被包装成fail结果保证单项失败不中断整体诊断。诊断结果通过GET /dashboard/diagnostics端点暴露并附带汇总摘要总检查数、通过/警告/失败数、overall_status。配置检查中有一段与监控主题直接相关的逻辑# Check configuration consistency if config.server.enable_health_check and not config.server.applicationinsights_connection_string: issues.append(Health check enabled but Application Insights not configured)它提醒了一个生产常见陷阱只开健康检查不配遥测等于有探针没眼睛——健康检查只能回答存活遥测才能回答性能与根因。运营 RunbookYAMLRunbook 把人肉经验沉淀为可执行的 YAML 文档。本 Lab 提供三个典型场景1. 数据库连接失败critical——四步排查docker-compose ps postgres/docker-compose logs postgres验证服务状态 →telnet postgres-host 5432验证网络 →curl http://localhost:8000/health/detailed检查连接池 →docker-compose restart重启服务并附升级路径联系 DBA、检查 Azure 基础设施。2. 高错误率high——docker-compose logs mcp_server | grep ERROR | tail -50定位日志 → 调用/dashboard/diagnostics分类错误 →curl http://localhost:8000/health/detailed排除资源压力 → 回溯最近部署 → 设置LOG_LEVELDEBUG临时加深日志。3. 查询性能缓慢medium——用pg_stat_statements定位最慢查询SELECT query, mean_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10随后检查pg_indexes索引覆盖、执行EXPLAIN ANALYZE分析执行计划、确认连接池未耗尽、用top -p $(pgrep postgres)监控查询期间资源。Runbook 与诊断引擎形成互补诊断引擎自动化执行检查Runbook 则记录人工介入的完整动作链与升级策略二者共同构成可运维性Operability的核心。关键要点总结完成本 Lab 后你的 MCP Server 应当具备✅Application Insights 集成完整的遥测与监控设置覆盖 HTTP、数据库、出站请求的自动插桩✅结构化日志生产就绪的 JSON 日志带关联 ID 与用户/RLS 上下文✅自定义指标业务与技术指标的采集与分析含 P95/P99✅智能告警规则驱动、多通道邮件/Teams/Slack、带冷却与解除通知的主动告警✅运营 DashboardWorkbook FastAPI 双通道实时监控与业务洞察✅故障排查自动化诊断引擎与可执行运营 Runbook。下一步继续学习 Lab 12: Best Practices and Optimization进一步掌握性能优化技术的应用复杂安全加固的实现生产部署的最佳实践成本优化策略其中包含 Application Insights 监控成本估算 的模型。本 Lab 与整个系列的关系可参考 11-MCPServerHandsOnLabs 学习路径总览前序 Lab 10: Deployment Strategies 负责把服务部署到 Azure Container Apps 并配置健康检查本 Lab 则赋予其生产级的观测能力。赞分享教程文档人工智能【免费下载链接】mcp-for-beginnersThis open-source curriculum introduces the fundamentals of Model Context Protocol (MCP) through real-world, cross-language examples in .NET, Java, TypeScript, JavaScript, Rust and Python. Designed for developers, it focuses on practical techniques for building modular, scalable, and secure AI workflows from session setup to service orchestration.项目地址https://gitcode.com/GitHub_Trending/mc/mcp-for-beginners点击查看免费下载相关推荐MCP 服务器监控与可观测性实战为生产级 MCP Server 搭建 Application Insights、结构化日志与智能告警MCP 服务器监控与可观测性实战为生产级 MCP Server 搭建 Application Insights、结构化日志与智能告警 导读 本文基于 mcp教程文档人工智能MCP 服务器生产级监控与可观测性实战基于 mcp-for-beginners 的 Application Insights、告警与故障排查完整指南MCP 服务器生产级监控与可观测性实战基于 mcp for beginners 的 Application Insights、告警与故障排查完整指南 本指南是教程文档人工智能MCP 服务器生产级监控与可观测性实战基于 Application Insights、结构化日志与智能告警的完整指南MCP 服务器生产级监控与可观测性实战基于 Application Insights、结构化日志与智能告警的完整指南 本文以 mcp for beginner教程文档人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考