Referenční architektura Azure IoT

Blob Storage
Functions
IoT Hub
Logic Apps
Stream Analytics

Tato referenční architektura ukazuje doporučenou architekturu pro aplikace IoT v Azure využívající komponenty PaaS (platforma jako služba).This reference architecture shows a recommended architecture for IoT applications on Azure using PaaS (platform-as-a-service) components.

Diagram architektury

Aplikace IoT je možné popsat jako věci (zařízení) odesílající data, ze kterých se generují přehledy.IoT applications can be described as things (devices) sending data that generates insights. Z těchto přehledů se generují akce vedoucí ke zlepšení podnikání nebo procesů.These insights generate actions to improve a business or process. Příkladem je motor (věc) odesílající data o teplotě.An example is an engine (the thing) sending temperature data. Tato data se použijí k vyhodnocení, jestli má motor očekávaný výkon (přehled).This data is used to evaluate whether the engine is performing as expected (the insight). Tento přehled se použije k aktivnímu určení priority plánu údržby motoru (akce).The insight is used to proactively prioritize the maintenance schedule for the engine (the action).

Tato referenční architektura využívá komponenty Azure PaaS (platforma jako služba).This reference architecture uses Azure PaaS (platform-as-a-service) components. Další doporučenou možností pro sestavování řešení IoT v Azure je:Another recommended option for building IoT solutions on Azure is:

  • IoT Central Azure.Azure IoT Central. IoT Central je plně spravované řešení SaaS (software jako služba).IoT Central is a fully managed SaaS (software-as-a-service) solution. Abstrahuje technické volby a umožňuje soustředit se výhradně na řešení.It abstracts the technical choices and lets you focus on your solution exclusively. Tato jednoduchost je vykoupená menšími možnostmi přizpůsobení než v případě řešení založeného na modelu PaaS.This simplicity comes with a tradeoff in being less customizable than a PaaS-based solution.

Existují dva základní způsoby zpracování telemetrických dat – kritická cesta a studená cesta.At a high level, there are two ways to process telemetry data, hot path and cold path. Liší se v požadavcích na latenci a přístup k datům.The difference has to do with requirements for latency and data access.

  • Kritická cesta analyzuje příchozí data téměř v reálném čase.The hot path analyzes data in near-real-time, as it arrives. V případě kritické cesty se telemetrická data musí zpracovat s velmi nízkou latencí.In the hot path, telemetry must be processed with very low latency. Kritická cesta se obvykle implementuje s využitím modulu pro zpracování streamů.The hot path is typically implemented using a stream processing engine. Výstup může aktivovat upozornění nebo se může zapsat do strukturovaného formátu, který je možné dotazovat pomocí analytických nástrojů.The output may trigger an alert, or be written to a structured format that can be queried using analytical tools.
  • Studená cesta provádí dávkové zpracování v delších intervalech (každou hodinu nebo každý den).The cold path performs batch processing at longer intervals (hourly or daily). Studená cesta obvykle zpracovává velké objemy dat, ale nemusí poskytovat výsledky tak rychle jako kritická cesta.The cold path typically operates over large volumes of data, but the results don't need to be as timely as the hot path. V případě studené cesty se nezpracovaná telemetrická data zachytávají a předávají do dávkového procesu.In the cold path, raw telemetry is captured and then fed into a batch process.

ArchitekturaArchitecture

Tato architektura se skládá z následujících komponent.This architecture consists of the following components. Některé aplikace nemusí vyžadovat všechny zde uvedené komponenty.Some applications may not require every component listed here.

Zařízení IoT.IoT devices. Zařízení se můžou bezpečně registrovat v cloudu a připojovat se ke cloudu za účelem odesílání a přijímání dat.Devices can securely register with the cloud, and can connect to the cloud to send and receive data. Některá zařízení můžou být hraniční zařízení, která provádí určité zpracování dat na samotném zařízení nebo v hraniční bráně.Some devices may be edge devices that perform some data processing on the device itself or in a field gateway. Pro účely zpracování na hraničních zařízení doporučujeme Azure IoT Edge.We recommend Azure IoT Edge for edge processing.

Cloudová brána.Cloud gateway. Cloudová brána zajišťuje cloudové centrum, které zařízením umožňuje bezpečně se připojit ke cloudu a odesílat data.A cloud gateway provides a cloud hub for devices to connect securely to the cloud and send data. Poskytuje také možnosti správy zařízení, včetně příkazů a ovládání zařízení.It also provides device management, capabilities, including command and control of devices. Jako cloudovou bránu doporučujeme IoT Hub.For the cloud gateway, we recommend IoT Hub. IoT Hub je hostovaná cloudová služba, která přijímá události ze zařízení a funguje jako zprostředkovatel zpráv mezi zařízeními a back-endovými službami.IoT Hub is a hosted cloud service that ingests events from devices, acting as a message broker between devices and backend services. IoT Hub zajišťuje zabezpečené připojení, příjem událostí, obousměrnou komunikaci a správu zařízení.IoT Hub provides secure connectivity, event ingestion, bidirectional communication, and device management.

Zřizování zařízení.Device provisioning. Pro účely registrace a připojování velkých sad zařízení doporučujeme použít službu IoT Hub Device Provisioning Service (DPS).For registering and connecting large sets of devices, we recommend using the IoT Hub Device Provisioning Service (DPS). DPS umožňuje přiřazovat a registrovat zařízení ke konkrétním koncovým bodům služby Azure IoT Hub ve velkém měřítku.DPS lets you assign and register devices to specific Azure IoT Hub endpoints at scale.

Zpracování streamů.Stream processing. Zpracování streamů analyzuje velké streamy datových záznamů a vyhodnocuje pravidla pro tyto streamy.Stream processing analyzes large streams of data records and evaluates rules for those streams. Pro účely zpracování streamů doporučujeme Azure Stream Analytics.For stream processing, we recommend Azure Stream Analytics. Stream Analytics dokáže provádět komplexní analýzy ve velkém měřítku s využitím funkcí pro práci s časovými intervaly, agregací streamů a spojování externích zdrojů dat.Stream Analytics can execute complex analysis at scale, using time windowing functions, stream aggregations, and external data source joins. Další možností je Apache Spark v Azure Databricks.Another option is Apache Spark on Azure Databricks.

Strojové učení umožňuje spouštění prediktivních algoritmů nad historickými telemetrickými daty a zajišťuje tak například scénáře prediktivní údržby.Machine learning allows predictive algorithms to be executed over historical telemetry data, enabling scenarios such as predictive maintenance. Pro účely strojového učení doporučujeme službu Azure Machine Learning.For machine learning, we recommend Azure Machine Learning.

Teplé úložiště cest uchovává data, která musí mít zařízení okamžitě k dispozici pro účely generování sestav a vizualizace.Warm path storage holds data that must be available immediately from device for reporting and visualization. Jako teplé úložiště cest doporučujeme Cosmos DB.For warm path storage, we recommend Cosmos DB. Cosmos DB je globálně distribuovaná databáze pro více modelů.Cosmos DB is a globally distributed, multi-model database.

Studené úložiště cest uchovává data, která se ukládají na delší dobu a používají k dávkovému zpracování.Cold path storage holds data that is kept longer-term and is used for batch processing. Jako studené úložiště cest doporučujeme Azure Blob Storage.For cold path storage, we recommend Azure Blob Storage. Data je možné archivovat po neomezenou dobu a s nízkými náklady v úložišti objektů blob, kde jsou snadno přístupná pro účely dávkového zpracování.Data can be archived in Blob storage indefinitely at low cost, and is easily accessible for batch processing.

Transformace dat manipuluje s datovým proudem telemetrie nebo ho agreguje.Data transformation manipulates or aggregates the telemetry stream. Mezi příklady patří transformace protokolu, například převod binárních dat do formátu JSON nebo kombinování datových bodů.Examples include protocol transformation, such as converting binary data to JSON, or combining data points. Pokud je potřeba data transformovat před tím, než dorazí do služby IoT Hub, doporučujeme použít protokolovou bránu (není zobrazená).If the data must be transformed before reaching IoT Hub, we recommend using a protocol gateway (not shown). Jinak je data možné transformovat po přijetí ve službě IoT Hub.Otherwise, data can be transformed after it reaches IoT Hub. V takovém případě doporučujeme používat řešení Azure Functions, které má vestavěnou integraci se službami IoT Hub, Cosmos DB a Blob Storage.In that case, we recommend using Azure Functions, which has built-in integration with IoT Hub, Cosmos DB, and Blob Storage.

Integrace obchodních procesů provádí akce na základě přehledů z dat zařízení.Business process integration performs actions based on insights from the device data. Může se jednat například o ukládání informačních zpráv, upozorňování, odesílání e-mailů nebo SMS zpráv nebo integraci s CRM.This could include storing informational messages, raising alarms, sending email or SMS messages, or integrating with CRM. Pro účely integrace obchodních procesů doporučujeme použít Azure Logic Apps.We recommend using Azure Logic Apps for business process integration.

Správa uživatelů omezuje, kteří uživatelé nebo skupiny můžou na zařízeních provádět akce, jako je upgrade firmwaru.User management restricts which users or groups can perform actions on devices, such as upgrading firmware. Kromě toho definuje možnosti uživatelů v aplikacích.It also defines capabilities for users in applications. K ověřování a autorizaci uživatelů doporučujeme použít Azure Active Directory.We recommend using Azure Active Directory to authenticate and authorize users.

Sledování zabezpečení Azure Security Center pro IoT poskytuje ucelené řešení zabezpečení pro úlohy IoT a zjednodušuje jejich ochranu tím, že nabízí sjednocenou viditelnost a kontrolu, prevenci adaptivních hrozeb a inteligentní detekci hrozeb a odezvu napříč úlohami ze zařízení ze seznamu na základě hran a také přes cloudy.Security monitoring Azure Security Center for IoT provides an end-to-end security solution for IoT workloads and simplifies their protection by delivering unified visibility and control, adaptive threat prevention, and intelligent threat detection and response across workloads from leaf devices through Edge as well as up through the clouds.

Aspekty zabezpečeníScalability considerations

Aplikace IoT by se měly sestavovat ze samostatných služeb, které se můžou nezávisle škálovat.An IoT application should be built as discrete services that can scale independently. Zvažte následující body týkající se škálovatelnosti:Consider the following scalability points:

IoTHub.IoTHub. U služby IoT Hub zvažte následující faktory škálování:For IoT Hub, consider the following scale factors:

  • Maximální denní kvóta zpráv odeslaných do služby IoT Hub.The maximum daily quota of messages into IoT Hub.
  • Kvóta připojených zařízení v jedné instanci služby IoT Hub.The quota of connected devices in an IoT Hub instance.
  • Propustnost příjmu — jak rychle může IoT Hub přijímat zprávy.Ingestion throughput — how quickly IoT Hub can ingest messages.
  • Propustnost zpracování — jak rychle se příchozí zprávy zpracovávají.Processing throughput — how quickly the incoming messages are processed.

Každé centrum IoT se zřizuje s určitým počtem jednotek na konkrétní úrovni.Each IoT hub is provisioned with a certain number of units in a specific tier. Úroveň a počet jednotek určují maximální denní kvótu zpráv, které můžou zařízení do centra odesílat.The tier and number of units determine the maximum daily quota of messages that devices can send to the hub. Další informace najdete v tématu Kvóty a omezování služby IoT Hub.For more information, see IoT Hub quotas and throttling. Kapacitu centra můžete vertikálně navýšit bez přerušení stávajících operací.You can scale up a hub without interrupting existing operations.

Stream Analytics.Stream Analytics. Úlohy Stream Analytics se škálují nejlépe, pokud jsou v kanálu Stream Analytics paralelní ve všech bodech, od vstupu přes dotazování až po výstup.Stream Analytics jobs scale best if they are parallel at all points in the Stream Analytics pipeline, from input to query to output. Úplně paralelní úloha umožňuje Stream Analytics rozdělit práci mezi několik výpočetních uzlů.A fully parallel job allows Stream Analytics to split the work across multiple compute nodes. Jinak musí Stream Analytics sloučit data streamu do jednoho místa.Otherwise, Stream Analytics has to combine the stream data into one place. Další informace najdete v tématu Využití paralelizace dotazů v Azure Stream Analytics.For more information, see Leverage query parallelization in Azure Stream Analytics.

IoT Hub automaticky rozděluje zprávy zařízení podle ID zařízení.IoT Hub automatically partitions device messages based on the device ID. Všechny zprávy z určitého zařízení vždy dorazí do stejného oddílu, ale jeden oddíl bude obsahovat zprávy z několika zařízení.All of the messages from a particular device will always arrive on the same partition, but a single partition will have messages from multiple devices. Proto je jednotkou paralelizace ID oddílu.Therefore, the unit of parallelization is the partition ID.

Funkce.Functions. Při čtení z koncového bodu služby Event Hubs platí maximální počet instancí funkce na oddíl centra událostí.When reading from the Event Hubs endpoint, there is a maximum of function instance per event hub partition. Maximální rychlost zpracování určuje, jak rychle dokáže jedna instance funkce zpracovat události z jednoho oddílu.The maximum processing rate is determined by how fast one function instance can process the events from a single partition. Funkce by zprávy měla zpracovávat v dávkách.The function should process messages in batches.

Cosmos DB.Cosmos DB. Pokud chcete horizontálně rozšířit kapacitu kolekce Cosmos DB, vytvořte kolekci s klíčem oddílu a vložte tento klíč oddílu do všech dokumentů, které zapisujete.To scale out a Cosmos DB collection, create the collection with a partition key and include the partition key in each document that you write. Další informace najdete v tématu Osvědčené postupy při výběru klíče oddílu.For more information, see Best practices when choosing a partition key.

  • Pokud pro každé zařízení ukládáte a aktualizujete jeden dokument, dobrým klíčem oddílu je ID zařízení.If you store and update a single document per device, the device ID is a good partition key. Zápisy se rovnoměrně distribuují mezi klíče.Writes are evenly distributed across the keys. Velikost každého oddílu je striktně omezená, protože pro každou hodnotu klíče existuje jeden dokument.The size of each partition is strictly bounded, because there is a single document for each key value.
  • Pokud pro každou zprávu zařízení ukládáte samostatný dokument, použitím ID zařízení jako klíče oddílu byste rychle překročili omezení 10 GB na oddíl.If you store a separate document for every device message, using the device ID as a partition key would quickly exceed the 10-GB limit per partition. V takovém případě je lepším klíčem oddílu ID zprávy.Message ID is a better partition key in that case. Obvykle budete do dokumentů stále vkládat ID zařízení pro účely indexování a dotazování.Typically you would still include device ID in the document for indexing and querying.

Azure Time Series Insights (TSI) je služba pro analýzy, ukládání a vizualizace pro data časových řad a poskytuje možnosti zahrnující filtrování a agregaci jako SQL, což řeší nutnost uživatelsky definovaných funkcí.Azure Time Series Insights (TSI) is an analytics, storage and visualization service for time-series data, providing capabilities including SQL-like filtering and aggregation, alleviating the need for user-defined functions. Time Series Insights poskytuje Průzkumník dat pro vizualizaci a dotazování dat i rozhraní REST API pro dotazy.Time Series Insights provides a data explorer to visualize and query data as well as REST Query APIs. Kromě dat Time Series je také TSI vhodná pro řešení, která vyžadují dotazování agregací pro velké datové sady dat.In addition to time series data, TSI is also well-suited for solutions that need to query aggregates over large sets of data. Díky podpoře pro vícevrstvé úložiště, bohatá rozhraní API, model a integraci s ekosystémem Azure IoT, průzkumníkem pro vizualizace a rozšiřitelnost prostřednictvím Power BI atd. TSI je naše doporučení pro ukládání a analýzu dat Time Series.With support for multi layered storage, rich APIs, model and it’s integration with Azure IoT ecosystem, explorer for visualizations, and extensibility through Power BI, etc. TSI is our recommendation for time series data storage and analytics.

Důležité informace o zabezpečeníSecurity considerations

Důvěryhodná a zabezpečená komunikaceTrustworthy and secure communication

Všechny informace přijaté ze zařízení nebo odeslané do zařízení musí být důvěryhodné.All information received from and sent to a device must be trustworthy. Pokud zařízení nepodporuje následující kryptografické funkce, mělo by být omezené na místní sítě a veškerá komunikace v síti by měla procházet přes hraniční bránu:Unless a device can support the following cryptographic capabilities, it should be constrained to local networks and all internetwork communication should go through a field gateway:

  • Šifrování dat s využitím prokazatelně zabezpečeného, veřejně analyzovaného a běžně implementovaného symetrického šifrovacího algoritmu.Data encryption with a provably secure, publicly analyzed, and broadly implemented symmetric-key encryption algorithm.
  • Digitální podpis s využitím prokazatelně zabezpečeného, veřejně analyzovaného a běžně implementovaného symetrického podpisového algoritmu.Digital signature with a provably secure, publicly analyzed, and broadly implemented symmetric-key signature algorithm.
  • Podpora protokolu TLS 1.2 pro komunikační trasy založené na protokolu TCP nebo jiném datovém proudu nebo protokolu DTLS 1.2 pro komunikační trasy založené na datagramech.Support for either TLS 1.2 for TCP or other stream-based communication paths or DTLS 1.2 for datagram-based communication paths. Podpora zpracování certifikátů X.509 je volitelná a v případě protokolu TLS se dá nahradit za režim předsdíleného klíče s efektivnějším využitím výpočetních a přenosových prostředků, který je možné implementovat s podporou algoritmů AES a SHA-2.Support of X.509 certificate handling is optional and can be replaced by the more compute-efficient and wire-efficient pre-shared key mode for TLS, which can be implemented with support for the AES and SHA-2 algorithms.
  • Aktualizovatelné klíče v úložišti klíčů a na jednotlivých zařízeních.Updateable key-store and per-device keys. Všechna zařízení musí mít jedinečný obsah klíčů nebo tokeny, které je identifikují v systému.Each device must have unique key material or tokens that identify it toward the system. Klíče by měly být bezpečně uložené na samotném zařízení (například s využitím zabezpečeného úložiště klíčů).The devices should store the key securely on the device (for example, using a secure key-store). Zařízení by mělo mít možnost klíče nebo tokeny aktualizovat, a to pravidelně nebo v reakci na krizové situace, jako je narušení systému.The device should be able to update the keys or tokens periodically, or reactively in emergency situations such as a system breach.
  • Software firmwaru a aplikací na zařízení musí umožňovat, aby aktualizace opravovaly zjištěná ohrožení zabezpečení.The firmware and application software on the device must allow for updates to enable the repair of discovered security vulnerabilities.

Řada zařízení je však příliš omezená a těmto požadavkům nevyhovuje.However, many devices are too constrained to support these requirements. V takovém případě by se měla použít hraniční brána.In that case, a field gateway should be used. Zařízení se zabezpečeně připojují k hraniční bráně přes místní síť a brána umožňuje zabezpečenou komunikaci s cloudem.Devices connect securely to the field gateway through a local area network, and the gateway enables secure communication to the cloud.

Fyzická ochrana před neoprávněnou manipulacíPhysical tamper-proofing

Důrazně doporučujeme, aby návrh zařízení zahrnoval funkce, které chrání před pokusy o fyzickou manipulaci a které pomůžou zajistit integritu zabezpečení a důvěryhodnost celého systému.It is strongly recommended that device design incorporates features that defend against physical manipulation attempts, to help ensure the security integrity and trustworthiness of the overall system.

Například:For example:

  • Vyberte mikrořadiče/mikroprocesory nebo pomocný hardware, které poskytují zabezpečené úložiště a používání materiálu kryptografických klíčů, jako je integrace čipu TPM (Trusted Platform Module).Choose microcontrollers/microprocessors or auxiliary hardware that provides secure storage and use of cryptographic key material, such as trusted platform module (TPM) integration.
  • Zabezpečený zavaděč spouštění a zabezpečené načítání softwaru ukotvené v modulu TPM.Secure boot loader and secure software loading, anchored in the TPM.
  • Použití senzorů, které detekují pokusy o neoprávněné vniknutí a manipulaci s prostředím zařízení, s funkcemi upozorňování a potenciálního digitálního samozničení zařízení.Use sensors to detect intrusion attempts and attempts to manipulate the device environment with alerting and potentially "digital self-destruction" of the device.

Další aspekty zabezpečení najdete v tématu Architektura zabezpečení Internetu věcí (IoT).For additional security considerations, see Internet of Things (IoT) security architecture.

Monitorování a protokolováníMonitoring and logging

Systémy protokolování a monitorování se používají k určení, jestli řešení funguje, a pomáhají s řešením problémů.Logging and monitoring systems are used to determine whether the solution is functioning and to help troubleshoot problems. Systémy protokolování a monitorování pomáhají zodpovědět následující provozní otázky:Monitoring and logging systems help answer the following operational questions:

  • Jsou zařízení nebo systémy v chybovém stavu?Are devices or systems in an error condition?
  • Jsou zařízení nebo systémy správně nakonfigurované?Are devices or systems correctly configured?
  • Generují zařízení nebo systémy přesná data?Are devices or systems generating accurate data?
  • Splňují systémy očekávání firmy i koncových zákazníků?Are systems meeting the expectations of both the business and end customers?

Nástroje pro protokolování a monitorování se obvykle skládají z následujících čtyř komponent:Logging and monitoring tools are typically comprised of the following four components:

  • Nástroje pro vizualizaci výkonu systému a časových os umožňující monitorování systému a základní řešení potíží.System performance and timeline visualization tools to monitor the system and for basic troubleshooting.
  • Příjem dat uložených ve vyrovnávací paměti umožňující ukládání dat protokolů do vyrovnávací paměti.Buffered data ingestion, to buffer log data.
  • Úložiště trvalosti umožňující ukládání dat protokolů.Persistence store to store log data.
  • Možnosti vyhledávání a dotazování umožňující zobrazení dat protokolů pro účely podrobného řešení potíží.Search and query capabilities, to view log data for use in detailed troubleshooting.

Systémy monitorování poskytují přehledy o stavu, zabezpečení, stabilitě a výkonu řešení IoT.Monitoring systems provide insights into the health, security, and stability, and performance of an IoT solution. Tyto systémy můžou poskytovat také podrobnější zobrazení, které zaznamenává změny konfigurace komponent a poskytuje extrahovaná data protokolování, která můžou odhalit potenciální ohrožení zabezpečení, zlepšit proces správy incidentů a pomoct vlastníkovi systému řešit potíže.These systems can also provide a more detailed view, recording component configuration changes and providing extracted logging data that can surface potential security vulnerabilities, enhance the incident management process, and help the owner of the system troubleshoot problems. Komplexní řešení monitorování zahrnují možnost dotazování informací z konkrétních subsystémů nebo agregace napříč několika subsystémy.Comprehensive monitoring solutions include the ability to query information for specific subsystems or aggregating across multiple subsystems.

Vývoj systému monitorování by měl začít definováním požadavků na bezproblémový provoz, dodržování legislativních předpisů a audit.Monitoring system development should begin by defining healthy operation, regulatory compliance, and audit requirements. Shromážděné metriky můžou zahrnovat:Metrics collected may include:

  • Fyzická zařízení, hraniční zařízení a komponenty infrastruktury hlásící změny konfigurace.Physical devices, edge devices, and infrastructure components reporting configuration changes.
  • Aplikace hlásící změny konfigurace, protokoly auditu zabezpečení, frekvence požadavků, doby odezvy, chybovosti a statistiky uvolňování paměti pro spravované jazyky.Applications reporting configuration changes, security audit logs, request rates, response times, error rates, and garbage collection statistics for managed languages.
  • Databáze, úložiště trvalosti a mezipaměti hlásící výkon při dotazování a zápisech, změny schématu, protokol auditu zabezpečení, zámky nebo zablokování, výkon indexů a využití procesorů, paměti a disků.Databases, persistence stores, and caches reporting query and write performance, schema changes, security audit log, locks or deadlocks, index performance, CPU, memory, and disk usage.
  • Spravované služby (IaaS, PaaS, SaaS a FaaS) hlásící metriky stavu a změny konfigurace, které ovlivňují stav a výkon závislého systému.Managed services (IaaS, PaaS, SaaS, and FaaS) reporting health metrics and configuration changes that impact dependent system health and performance.

Vizualizace metrik monitorování upozorňují operátory na nestability systému a usnadňují reakci na incidenty.Visualization of monitoring metrics alert operators to system instabilities and facilitate incident response.

Trasování telemetrieTracing telemetry

Trasování telemetrie umožňuje operátorům sledovat cestu částí telemetrických dat celým systémem od jejich vytvoření.Tracing telemetry allows an operator to follow the journey of a piece of telemetry from creation through the system. Trasování je důležité při ladění a řešení potíží.Tracing is important for debugging and troubleshooting. V případě řešení IoT, která využívají Azure IoT Hub a sady SDK pro zařízení IoT Hub, můžou diagramy trasování vznikat jako zprávy ve směru cloud-zařízení a vkládat se do datového proudu telemetrie.For IoT solutions that use Azure IoT Hub and the IoT Hub Device SDKs, tracing datagrams can be originated as Cloud-to-Device messages and included in the telemetry stream.

ProtokolováníLogging

Systémy protokolování hrají zcela zásadní roli při zjišťování, jaké akce nebo aktivity určité řešení provedlo a k jakým chybám došlo, a můžou být nápomocné při opravě těchto chyb.Logging systems are integral in understanding what actions or activities a solution has performed, failures that have occurred, and can provide help in fixing those failures. Analýza protokolů může pomoct s pochopením a nápravou chybových podmínek, zlepšením výkonových charakteristik a zajištěním dodržování platných předpisů a právních úprav.Logs can be analyzed to help understand and remedy error conditions, enhance performance characteristics, and ensure compliance with governing rule and regulations.

Přestože protokolování prostého textu s sebou nese menší počáteční náklady na vývoj, parsování a čtení je pro počítač složitější.Though plain-text logging is lower impact on upfront development costs, it is more challenging for a machine to parse/read. Doporučujeme použít strukturované protokolování, protože shromážděné informace jsou parsovatelné počítačem i lidsky čitelné.We recommend structured logging be used, as collected information is both machine parsable and human readable. Strukturované protokolování přidává k informacím o protokolech situační kontext a metadata.Structured logging adds situational context and metadata to the log information. Ve strukturovaném protokolování jsou prvořadé vlastnosti formátované jako páry klíč-hodnota nebo s pevným schématem, které zlepšují možnosti vyhledávání a dotazování.In structured logging, properties are first class citizens formatted as key/value pairs, or with a fixed schema, to enhance search and query capabilities.

Důležité informace o DevOpsDevOps considerations

Použijte infrastrukturu jako kód (IaC).Use the Infrastructure as code (IaC). IaC je správa infrastruktury (sítí, virtuálních počítačů, nástrojů pro vyrovnávání zatížení a topologie připojení) s deklarativním přístupem.IaC is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) with a declarative approach. Šablony by měly být ve verzi a musí být součástí kanálu vydání.Templates should be versioned and part of the release pipeline. Nejspolehlivější procesy nasazení jsou automatizované a idempotentní.The most reliable deployment processes are automated and idempotent. Jedním ze způsobů, jak vytvořit šablonu Azure Resource Manager pro zřizování prostředků IoT a infrastruktury.One way is to create Azure Resource Manager template for provisioning the IoT resources and the infrastructure.

K automatizaci nasazení infrastruktury můžete použít Azure DevOps Services, Jenkinse nebo jiná řešení CI/CD.To automate infrastructure deployment, you can use Azure DevOps Services, Jenkins, or other CI/CD solutions. Azure Pipelines je součástí Azure DevOps Services a spouští automatizovaná sestavení, testy a nasazení.Azure Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments.

Zvažte přípravu zátěže nasazením do různých fází a spuštění ověření v každé fázi před přechodem na další. tímto způsobem můžete nabízet aktualizace do vašich produkčních prostředí vysoce kontrolovaným způsobem a minimalizovat neočekávané problémy s nasazením.Consider staging your workloads by deploying to various stages and running validations at each stage before moving on to the next one; that way you can push updates to your production environments in a highly controlled way and minimize unanticipated deployment issues. Nasazení Blue-zelená a Kanárské verze jsou doporučenými strategiemi nasazení pro aktualizace živých produkčních prostředí.Blue-green deployment and Canary releases are recommended deployment strategies for updating live production environments. Zvažte také dobrou strategii vrácení zpět pro případ, kdy nasazení dojde k chybě. Můžete například automaticky znovu nasadit dřívější úspěšné nasazení z historie nasazení, takže parametr--rollback-On-Error v rozhraní příkazového řádku Azure je dobrým příkladem.Also consider having a good rollback strategy for when a deployment fails; for example you could automatically redeploy an earlier, successful deployment from your deployment history, the --rollback-on-error flag parameter in Azure CLI is good example.

Zvažte monitorování řešení pomocí Azure monitor.Consider monitoring your solution by using Azure Monitor. Azure Monitor je hlavním zdrojem monitorování a protokolování pro všechny služby Azure, poskytuje diagnostické informace o prostředcích Azure.Azure Monitor is the main source of monitoring and logging for all your Azure services, it provides diagnostics information for Azure resources. Můžete například monitorovat operace, které probíhají v rámci služby IoT Hub.You can for example, monitor the operations that take place within your IoT hub. K dispozici jsou konkrétní metriky a události, které Azure Monitor podporuje, stejně jako služby, schémata a kategorie pro diagnostické protokoly Azure.There are specific metrics and events that Azure Monitor supports, as well as services, schemas, and categories for Azure Diagnostic Logs.

Další informace naleznete v části DevOps v tématu Microsoft Azure Well-Architected Framework.For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

Důležité informace o nákladechCost considerations

Obecně platí, že pomocí cenové kalkulačky Azure můžete odhadnout náklady.In general, use the Azure pricing calculator to estimate costs. Další požadavky jsou popsány v části cost v Microsoft Azure Well-Architected Framework.Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework.

Existují způsoby, jak optimalizovat náklady spojené se službami používanými v této referenční architektuře.There are ways to optimize costs associated the services used in this reference architecture.

Azure IoT HubAzure IoT Hub

V této architektuře je IoT Hub cloudovou bránou, která ingestuje události ze zařízení.In this architecture, IoT Hub is the cloud gateway that ingests events from devices. Fakturace IoT Hub se liší v závislosti na typu operace.IoT Hub billing varies depending on the type of operation. Vytváření, aktualizace, vkládání a odstraňování je zdarma.Create, update, insert, delete are free. U úspěšných operací, jako jsou třeba zprávy typu zařízení-Cloud a Cloud-zařízení, se účtují poplatky.Successful operations such as device-to-cloud and cloud-to-device messages are charged.

Zprávy ze zařízení do cloudu, které se úspěšně odeslaly, se účtují ve 4 KB blocích na vstupu do IoT Hub.Device-to-cloud messages sent successfully are charged in 4-KB chunks on ingress into IoT Hub. Například zpráva o 6 – KB se účtuje jako dvě zprávy.For example, a 6-KB message is charged as two messages.

IoT Hub udržuje informace o stavu jednotlivých připojených zařízení v dokumentu JSON s dvojitou příponou zařízení.IoT Hub maintains state information about each connected device in a device twin JSON document. Účtují se operace čtení z dokumentu s dvojitou podmnožinou zařízení.Read operations from a device twin document are charged.

IoT Hub nabízí dvě úrovně: Basic a Standard.IoT Hub offers two tiers: Basic and Standard.

Pokud vaše architektura IoT používá možnosti obousměrné komunikace, zvažte použití úrovně Standard .Consider using the Standard tier if your IoT architecture uses bi-directional communication capabilities. Tato vrstva také nabízí bezplatnou edici, která je pro účely testování nejvíce vhodná.This tier also offers a free edition that is most suited for testing purposes.

Pokud potřebujete jenom jednosměrnou komunikaci ze zařízení do cloudu, použijte úroveň Basic , která je levnější.If you only need uni-directional communication from devices to the cloud, use the Basic tier, which is cheaper.

Další informace najdete v tématu IoT Hub ceny.For more information, see IoT Hub Pricing.

Azure Stream AnalyticsAzure Stream Analytics

Azure Stream Analytics se používá pro vyhodnocení zpracování a pravidel streamování.Azure Stream Analytics is used for stream processing and rules evaluation. Ceny Azure Stream Analytics se účtují podle počtu jednotek streamování (SU) za hodinu, které přicházejí do výpočtů, paměti a propustnosti potřebných ke zpracování dat.Azure Stream Analytics is priced by the number of Streaming Units (SU) per hour, which takes into compute, memory, and throughput required to process the data. Azure Stream Analytics na IoT Edge se účtuje na úlohu.Azure Stream Analytics on IoT Edge is billed per job. Fakturace začíná při nasazení Stream Analytics úlohy do zařízení bez ohledu na stav úlohy, spuštění, selhání nebo zastavení.Billing starts when a Stream Analytics job is deployed to devices regardless of the job status, running, failed, or stopped.

Další informace o cenách najdete v tématu Stream Analytics ceny.For more information about pricing, see Stream Analytics pricing.

Azure FunctionsAzure Functions

Azure Functions slouží k transformaci dat poté, co dosáhne IoT Hub.Azure Functions is used to transform data after it reaches the IoT Hub. Z hlediska nákladů je doporučeno použít plán spotřeby , protože platíte pouze za výpočetní prostředky, které používáte.From a cost perspective, the recommendation is to use consumption plan because you pay only for the compute resources you use. Poplatky se účtují na základě využití prostředků za sekundu pokaždé, když událost aktivuje provedení funkce.You are charged based on per-second resource consumption each time an event triggers the execution of the function. Zpracování několika událostí v jednom provedení nebo dávkách může snížit náklady.Processing several events in a single execution or batches can reduce cost.

Azure Logic AppsAzure Logic Apps

V této architektuře se Logic Apps používá pro integraci obchodních procesů.In this architecture, Logic Apps is used for business process integration.

Ceny Logic Apps fungují na modelu průběžných plateb.Logic apps pricing works on the pay-as-you-go model. Triggery, akce a spuštění konektoru jsou měřeny pokaždé, když se spustí aplikace logiky.Triggers, actions, and connector executions are metered each time a logic app runs. Všechny úspěšné a neúspěšné akce, včetně triggerů, se považují za spuštění.All successful and unsuccessful actions, including triggers, are considered as executions.

Například vaše aplikace logiky zpracovává 1000 zpráv denně.For instance, your logic app processes 1000 messages a day. Pracovní postup s pěti akcemi bude nižší než $6.A workflow of five actions will cost less than $6.

Další informace najdete v tématu Logic Apps ceny.For more information, see Logic Apps pricing.

Úložiště datData Storage

Pro ukládání studených cest je Azure Blob Storage nejúčinnější volbou.For cold path storage, Azure Blob Storage is the most cost-effective option.

Pro úložiště teplé cesty zvažte použití Azure Cosmos DB.For warm path storage, consider using Azure Cosmos DB. Další informace najdete v tématu Cosmos DB ceny.For more information, see Cosmos DB pricing.

Další krokyNext steps