Azure IoT-referenciaarchitektúra

Blob Storage
Functions
IoT Hub
Logic Apps
Stream Analytics

Ez a referenciaarchitektúra egy javasolt architektúrát mutat be az Azure-on futó IoT-alkalmazásokhoz PaaS- (szolgáltatásként nyújtott platform) összetevőkkel.This reference architecture shows a recommended architecture for IoT applications on Azure using PaaS (platform-as-a-service) components.

Az architektúra ábrája

Az IoT-alkalmazásokban lényegében az eszközök adatokat küldenek, amelyekből megállapítások jönnek létre.IoT applications can be described as things (devices) sending data that generates insights. Ezek a megállapítások aztán műveleteket indítanak az üzletmenet vagy valamely folyamat javítására.These insights generate actions to improve a business or process. Vegyünk például egy motort (az eszköz), amely hőmérsékletadatokat küld.An example is an engine (the thing) sending temperature data. Az adatok alapján a rendszer kiértékeli, hogy a motor a várakozásnak megfelelően működik-e (a megállapítás).This data is used to evaluate whether the engine is performing as expected (the insight). A megállapítás alapján proaktívan rangsorolható a motor karbantartásának ütemezése (a művelet).The insight is used to proactively prioritize the maintenance schedule for the engine (the action).

Ez a referenciaarchitektúra Azure PaaS- (szolgáltatásként nyújtott platform) összetevőket használ.This reference architecture uses Azure PaaS (platform-as-a-service) components. Egy másik ajánlott lehetőség az Azure-beli IoT-megoldások létrehozásához:Another recommended option for building IoT solutions on Azure is:

  • Azure IoT Central.Azure IoT Central. Az IoT Central egy teljeskörűen felügyelt SaaS- (szolgáltatásként nyújtott szoftver) megoldás.IoT Central is a fully managed SaaS (software-as-a-service) solution. Absztrahálja a műszaki választásokat, így Önnek kizárólag a megoldásra összpontosíthat.It abstracts the technical choices and lets you focus on your solution exclusively. Az egyszerűségért cserébe kevésbé testreszabható, mint a PaaS-alapú megoldások.This simplicity comes with a tradeoff in being less customizable than a PaaS-based solution.

Magas szinten a telemetriaadatok feldolgozásának két módja van, a gyakori és a ritka elérésű útvonalak.At a high level, there are two ways to process telemetry data, hot path and cold path. A különbség a késésre és az adatelérésre vonatkozó követelményekben rejlik.The difference has to do with requirements for latency and data access.

  • A gyakori elérésű útvonal közel valós időben elemzi a beérkező adatokat.The hot path analyzes data in near-real-time, as it arrives. A gyakori elérésű útvonalon a telemetriát rendkívül kis késéssel kell feldolgozni.In the hot path, telemetry must be processed with very low latency. A gyakori elérésű útvonalakat általában egy streamfeldolgozó motorral valósítják meg.The hot path is typically implemented using a stream processing engine. A kimenet aktiválhat egy riasztást, vagy kiírható egy strukturált formátumba, amely aztán elemzőeszközökkel lekérdezhető.The output may trigger an alert, or be written to a structured format that can be queried using analytical tools.
  • A ritka elérésű útvonal kötegelt feldolgozást végez hosszabb időközönként (óránként vagy naponta).The cold path performs batch processing at longer intervals (hourly or daily). A ritka elérésű útvonal általában nagy mennyiségű adatot kezel, de az eredményeknek nem kell olyan időszerűnek lenniük, mint a gyakori elérési útvonalnál.The cold path typically operates over large volumes of data, but the results don't need to be as timely as the hot path. A ritka elérésű útvonalon rögzített nyers telemetriaadatokat egy kötegelt folyamatba táplálja be a rendszer.In the cold path, raw telemetry is captured and then fed into a batch process.

ArchitektúraArchitecture

Az architektúra az alábbi összetevőkből áll.This architecture consists of the following components. Nem minden alkalmazáshoz szükséges az itt felsorolt összes összetevő.Some applications may not require every component listed here.

IoT-eszközök.IoT devices. Az eszközök biztonságosan regisztrálhatnak a felhőben, majd a felhőre csatlakozva küldhetnek és fogadhatnak adatokat.Devices can securely register with the cloud, and can connect to the cloud to send and receive data. Egyes eszközök lehetnek peremhálózati eszközök, amelyek az adatfeldolgozás egy részét magán az eszközön vagy egy helyszíni átjárón végzik.Some devices may be edge devices that perform some data processing on the device itself or in a field gateway. A peremhálózati feldolgozáshoz az Azure IoT Edge használatát javasoljuk.We recommend Azure IoT Edge for edge processing.

Felhőátjáró.Cloud gateway. A felhőátjáró egy felhőalapú központot biztosít az eszközök számára, amelyen keresztül biztonságosan csatlakozhatnak a felhőhöz és küldhetnek adatokat.A cloud gateway provides a cloud hub for devices to connect securely to the cloud and send data. Emellett eszközkezelési képességeket is kínál, többek között az eszközök irányítását és vezérlését.It also provides device management, capabilities, including command and control of devices. A felhőátjárókhoz az IoT Hub használatát javasoljuk.For the cloud gateway, we recommend IoT Hub. Az IoT Hub egy üzemeltetett felhőszolgáltatás, amely üzenetközvetítőként működik az eszközök és a háttérszolgáltatások között.IoT Hub is a hosted cloud service that ingests events from devices, acting as a message broker between devices and backend services. Az IoT Hub biztonságos kapcsolódási, eseménybetöltési, kétirányú kommunikációs és eszközkezelési képességeket biztosít.IoT Hub provides secure connectivity, event ingestion, bidirectional communication, and device management.

Eszközkiépítés.Device provisioning. Eszközök mennyiségi regisztrálása és csatlakoztatása esetén az IoT Hub Device Provisioning Service (DPS) használatát javasoljuk.For registering and connecting large sets of devices, we recommend using the IoT Hub Device Provisioning Service (DPS). A DPS segítségével nagy mennyiségben oszthat ki és regisztrálhat eszközöket adott Azure IoT Hub-végpontokra.DPS lets you assign and register devices to specific Azure IoT Hub endpoints at scale.

Streamfeldolgozás.Stream processing. A streamfeldolgozás nagy méretű adatrekordstreameket dolgoz fel, és szabályokat értékel ki ezekre a streamekre.Stream processing analyzes large streams of data records and evaluates rules for those streams. Streamfeldolgozáshoz az Azure Stream Analytics használatát javasoljuk.For stream processing, we recommend Azure Stream Analytics. A Stream Analytics használatával összetett elemzéseket hajthatók végre nagy adatmennyiségeken időablak-készítési függvényekkel, streamaggregációkkal, valamint külső adatforrások összekapcsolásával.Stream Analytics can execute complex analysis at scale, using time windowing functions, stream aggregations, and external data source joins. Egy másik lehetőség az Apache Spark és az Azure Databricks használata.Another option is Apache Spark on Azure Databricks.

A gépi tanulás révén prediktív algoritmusok hajthatók végre telemetria-előzményadatok alapján, így például prediktív karbantartási és hasonló forgatókönyvek alakíthatók ki.Machine learning allows predictive algorithms to be executed over historical telemetry data, enabling scenarios such as predictive maintenance. A gépi tanuláshoz az Azure Machine Learning használatát javasoljuk.For machine learning, we recommend Azure Machine Learning.

A közepes elérésű tárolás olyan adatokat tárol, amelyeknek azonnal elérhetőnek kell lenniük az eszközön jelentéskészítési és vizualizációs célokra.Warm path storage holds data that must be available immediately from device for reporting and visualization. Közepes elérésű tároláshoz a Cosmos DB használatát javasoljuk.For warm path storage, we recommend Cosmos DB. A Cosmos DB egy globálisan elosztott, többmodelles adatbázis.Cosmos DB is a globally distributed, multi-model database.

A ritka elérésű tárolás hosszabb távra megőrzött és kötegelten feldolgozott adatokat tárol.Cold path storage holds data that is kept longer-term and is used for batch processing. Ritka elérésű tároláshoz az Azure Blob Storage használatát javasoljuk.For cold path storage, we recommend Azure Blob Storage. Az adatok a Blob Storage-tárolókban határozatlan időre alacsony áron archiválhatók, és könnyen elérhetők kötegelt feldolgozásra.Data can be archived in Blob storage indefinitely at low cost, and is easily accessible for batch processing.

Az adatátalakítás a telemetriastreamet módosítja és összesíti.Data transformation manipulates or aggregates the telemetry stream. Ilyen módosítások a protokollátalakítások is, például a bináris adatok JSON-formátumba való alakítása vagy az adatpontok kombinálása.Examples include protocol transformation, such as converting binary data to JSON, or combining data points. Ha az adatokat át kell alakítani az IoT Hub elérése előtt, javasoljuk egy protokoll-átjáró használatát (az ábrán nem szerepel).If the data must be transformed before reaching IoT Hub, we recommend using a protocol gateway (not shown). Ellenkező esetben az adatok az IoT Hub elérése után alakíthatók át.Otherwise, data can be transformed after it reaches IoT Hub. Ebben az esetben az Azure Functions használatát javasoljuk, amely beépített IoT Hub-, Cosmos DB- és Blob Storage-integrációval rendelkezik.In that case, we recommend using Azure Functions, which has built-in integration with IoT Hub, Cosmos DB, and Blob Storage.

Az üzletifolyamat-integráció műveleteket hajt végre az eszközadatokból táplálkozó megállapítások alapján.Business process integration performs actions based on insights from the device data. Ilyen művelet lehet a tájékoztató üzenetek tárolása, a riasztások létrehozása, az e-mail- vagy SMS-üzenetek küldése vagy a CRM-integráció.This could include storing informational messages, raising alarms, sending email or SMS messages, or integrating with CRM. Az üzletifolyamat-integrációhoz az Azure Logic Apps használatát javasoljuk.We recommend using Azure Logic Apps for business process integration.

A felhasználókezeléssel szabályozható, hogy mely felhasználók vagy csoportok hajthatnak végre műveleteket az eszközökön, például frissíthetik a belső vezérlőprogramot.User management restricts which users or groups can perform actions on devices, such as upgrading firmware. Ez emellett a felhasználók alkalmazásokon belüli képességeit is szabályozza.It also defines capabilities for users in applications. A felhasználók hitelesítéséhez és engedélyezéséhez az Azure Active Directory használatát javasoljuk.We recommend using Azure Active Directory to authenticate and authorize users.

A IoT biztonsági monitorozási Azure Security Center teljes körű biztonsági megoldást nyújt a IoT számítási feladatokhoz, és egyszerűbbé teszi a védelmet azáltal, hogy egységes láthatóságot és vezérlést, adaptív veszélyforrások megelőzését, valamint intelligens veszélyforrások észlelését és reagálást tesz lehetővé a levelektől az Edge-eszközökön, valamint a felhőn keresztül.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.

Méretezési szempontokScalability considerations

Az IoT-alkalmazásokat egymástól függetlenül méretezhető, különálló szolgáltatásokként érdemes megvalósítani.An IoT application should be built as discrete services that can scale independently. A méretezés során a következő szempontokat érdemes figyelembe vennie:Consider the following scalability points:

IoTHub.IoTHub. Az IoT Hub esetében a következő méretezési tényezők lépnek fel:For IoT Hub, consider the following scale factors:

  • Az IoT Hubba naponta maximálisan küldhető üzenetek kvótája.The maximum daily quota of messages into IoT Hub.
  • Az egyes IoT Hub-példányokon csatlakoztatott eszközök kvótája.The quota of connected devices in an IoT Hub instance.
  • Betöltési sebesség — milyen gyorsan képes az IoT Hub betölteni az üzeneteket.Ingestion throughput — how quickly IoT Hub can ingest messages.
  • Feldolgozási sebesség — mennyi időt vesz igénybe a bejövő üzenetek feldolgozása.Processing throughput — how quickly the incoming messages are processed.

Üzembe helyezéskor minden IoT hub bizonyos számú egységet tartalmaz egy adott szinten.Each IoT hub is provisioned with a certain number of units in a specific tier. A szint és az egységek száma határozza meg az eszközök által naponta a hubra maximálisan küldhető üzenetek kvótáját.The tier and number of units determine the maximum daily quota of messages that devices can send to the hub. További információkért lásd: Az IoT Hub kvótái és szabályozása.For more information, see IoT Hub quotas and throttling. A hubok a folyamatban lévő műveletek megszakítása nélkül skálázhatók fel vertikálisan.You can scale up a hub without interrupting existing operations.

Stream Analytics.Stream Analytics. A Stream Analytics-feladatok legjobban akkor méretezhetők, ha a Stream Analytics-folyamat minden pontján párhuzamosak, a bemenettől a lekérdezésen keresztül a kimenetig.Stream Analytics jobs scale best if they are parallel at all points in the Stream Analytics pipeline, from input to query to output. A teljes mértékben párhuzamos feladatokban a Stream Analytics több számítási csomópont között tudja szétosztani a munkát.A fully parallel job allows Stream Analytics to split the work across multiple compute nodes. Máskülönben a Stream Analyticsnek egy helyen kell kombinálnia a streamadatokat.Otherwise, Stream Analytics has to combine the stream data into one place. További információért lásd az Azure Stream Analytics-lekérdezések párhozamosításának előnyeit ismertető cikket.For more information, see Leverage query parallelization in Azure Stream Analytics.

Az IoT Hub automatikusan particionálja az eszközüzeneteket az eszközazonosító alapján.IoT Hub automatically partitions device messages based on the device ID. Egy adott eszközről az összes üzenet mindig ugyanarra a partícióra érkezik, egy partícióra azonban több eszközről is érkeznek üzenetek.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. A párhuzamosításhoz használt egység tehát a partícióazonosító.Therefore, the unit of parallelization is the partition ID.

Függvények.Functions. Az Event Hubs-végpont olvasásakor meg van határozva a függvénypéldányok maximális száma eseményközpont-partíciónként.When reading from the Event Hubs endpoint, there is a maximum of function instance per event hub partition. A maximális feldolgozási sebességét az határozza meg, hogy egy függvénypéldány milyen gyorsan képes feldolgozni az eseményeket egyetlen partícióról.The maximum processing rate is determined by how fast one function instance can process the events from a single partition. A függvénynek kötegekben érdemes feldolgoznia az üzeneteket.The function should process messages in batches.

Cosmos db.Cosmos DB. Egy Cosmos DB-gyűjtemény horizontális felskálázásához egy partíciókulccsal hozza létre a gyűjteményt, és a partíciókulcsot minden Ön által írt dokumentumban szerepeltesse.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. További információért lásd a partíciókulcsokkal kapcsolatos ajánlott eljárásokat ismertető szakaszt.For more information, see Best practices when choosing a partition key.

  • Ha eszközönként egyetlen dokumentumot tárol, és azt frissíti, az eszköz azonosítója megfelelő partíciókulcs.If you store and update a single document per device, the device ID is a good partition key. Az írási műveletek egyenlően oszlanak el a kulcsok között.Writes are evenly distributed across the keys. Az egyes partíciók mérete szigorúan korlátozva van, mivel mindegyik kulcsértékhez csak egyetlen dokumentum tartozik.The size of each partition is strictly bounded, because there is a single document for each key value.
  • Ha eszközüzenetenként külön dokumentumot tárol, hamar túllépné a partíciónkénti 10 GB-os korlátot, ha az eszközazonosítót használná partíciókulcsként.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. Az üzenetazonosító ebben az esetben megfelelőbb partíciókulcs.Message ID is a better partition key in that case. Az eszközazonosítót ilyen esetben is érdemes belefoglalnia a dokumentumba indexelési és lekérdezési célokkal.Typically you would still include device ID in the document for indexing and querying.

A Azure Time Series Insights (ÁME) egy elemzési, tárolási és vizualizációs szolgáltatás az idősoros adatokhoz, beleértve az SQL-hez hasonló szűrést és összesítést, ami csökkenti a felhasználó által definiált függvények igényét.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. A Time Series Insights adatkezelőt biztosít az adatok megjelenítéséhez és lekérdezéséhez, valamint a REST lekérdezési API-khoz.Time Series Insights provides a data explorer to visualize and query data as well as REST Query APIs. Az idősorozat-adatok mellett az ÁME olyan megoldások esetében is megfelelő, amelyeknek nagy adathalmazokon keresztül kell lekérdezni az összesítéseket.In addition to time series data, TSI is also well-suited for solutions that need to query aggregates over large sets of data. A többrétegű tárolás, a sokoldalú API-k, a modell és az Azure IoT-ökoszisztémával való integráció, a vizualizációk megjelenítése és a bővíthetőség Power BI stb. révén. Az ÁME a Time Series adattárolási és-elemzési javaslata.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.

Biztonsági szempontokSecurity considerations

Megbízható és biztonságos kommunikációTrustworthy and secure communication

Az eszközökről érkező és a nekik küldött összes üzenetnek megbízhatónak kell lennie.All information received from and sent to a device must be trustworthy. Ha egy eszköz nem támogatja az alábbi titkosítási funkciókat, a helyi hálózatokra kell korlátoznia, és a hálózatok közötti összes kommunikációnak helyszíni átjárókon keresztül kell zajlania: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:

  • Adattitkosítás egy bizonyíthatóan biztonságos, nyilvánosan elemzett és széles körben bevezetett, szimmetrikus kulcsú titkosítási algoritmussal.Data encryption with a provably secure, publicly analyzed, and broadly implemented symmetric-key encryption algorithm.
  • Digitális aláírás egy bizonyíthatóan biztonságos, nyilvánosan elemzett és széles körben bevezetett, szimmetrikus kulcsú aláírási algoritmussal.Digital signature with a provably secure, publicly analyzed, and broadly implemented symmetric-key signature algorithm.
  • A TLS 1.2 támogatása a TCP- vagy egyéb streamalapú kommunikációs útvonalakon, vagy a DTLS 1.2 támogatása a datagramalapú kommunikációs útvonalakon.Support for either TLS 1.2 for TCP or other stream-based communication paths or DTLS 1.2 for datagram-based communication paths. Az X.509 tanúsítvány kezelésének támogatása nem kötelező, és kiváltható a TLS számítási és átviteli szempontból hatékonyabb előre megosztott kulcsú módjával, amely az AES és az SHA-2 algoritmusok támogatásával is megvalósítható.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.
  • Frissíthető kulcstároló és eszközönkénti kulcsok.Updateable key-store and per-device keys. Minden eszköznek egyedi kulcsadatokkal vagy jogkivonatokkal kell rendelkeznie, amelyek azonosítják a rendszer felé.Each device must have unique key material or tokens that identify it toward the system. Az eszközök kulcsait biztonságosan, magukon az eszközökön kell tárolni (például egy biztonságos kulcstárolóval).The devices should store the key securely on the device (for example, using a secure key-store). Az eszközöknek képesnek kell lenniük a kulcsok vagy jogkivonatok rendszeres időközönként, illetve vészhelyzet (pl. a rendszer feltörésekor) esetén történő reaktív frissítésére.The device should be able to update the keys or tokens periodically, or reactively in emergency situations such as a system breach.
  • Az eszközök belső vezérlőprogramjának és a rajtuk lévő alkalmazásszoftvereknek engedélyezniük kell a frissítéseket a felfedezett biztonsági rések javítása érdekében.The firmware and application software on the device must allow for updates to enable the repair of discovered security vulnerabilities.

Számos eszköz azonban túlzottan korlátozott, és nem tudja támogatni ezeket a követelményeket.However, many devices are too constrained to support these requirements. Ilyen esetben helyszíni átjárót érdemes használnia.In that case, a field gateway should be used. Az eszközök biztonságosan kapcsolódnak a helyszíni átjáróhoz egy helyi hálózaton keresztül, és az átjáró teszi lehetővé a biztonságos kommunikációt a felhő felé.Devices connect securely to the field gateway through a local area network, and the gateway enables secure communication to the cloud.

Illetéktelen fizikai hozzáférés megakadályozásaPhysical tamper-proofing

Erősen ajánlott az eszközt úgy kialakítani, hogy védelmet nyújtson az illetéktelen hozzáférésre irányuló fizikai kísérletek ellen, és így segítsen biztosítani a teljes rendszer biztonsági integritását és megbízhatóságát.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.

Például:For example:

  • Válasszon olyan mikroprocesszorokat/mikroprocesszorokat vagy kiegészítő hardvereket, amelyek biztonságos tárolást és titkosítási kulcsokat használnak, például a platformmegbízhatósági modul (TPM) integrációját.Choose microcontrollers/microprocessors or auxiliary hardware that provides secure storage and use of cryptographic key material, such as trusted platform module (TPM) integration.
  • Biztonságos rendszertöltő és biztonságos szoftverbetöltés, amelyeket a TPM biztosít.Secure boot loader and secure software loading, anchored in the TPM.
  • Használjon érzékelőket a behatolási kísérletek és az eszköz környezetének illetéktelen módosítására irányuló kísérletek felderítésére, riasztásokkal és az eszköz lehetséges „digitális önmegsemmisítésével”.Use sensors to detect intrusion attempts and attempts to manipulate the device environment with alerting and potentially "digital self-destruction" of the device.

A további biztonsági szempontokért lásd az eszközök internetes hálózatának (IoT) biztonsági architektúráját ismertető szakaszt.For additional security considerations, see Internet of Things (IoT) security architecture.

Monitorozás és naplózásMonitoring and logging

A naplózó és monitorozó rendszerekkel megállapítható, hogy a megoldás jól működik-e, emellett használhatók a hibaelhárítás támogatására is.Logging and monitoring systems are used to determine whether the solution is functioning and to help troubleshoot problems. A monitorozó és naplózó rendszerekkel megválaszolhatók az alábbi üzemeltetési kérdések:Monitoring and logging systems help answer the following operational questions:

  • Hibásak az eszközök vagy rendszerek?Are devices or systems in an error condition?
  • Megfelelően vannak konfigurálva az eszközök vagy rendszerek?Are devices or systems correctly configured?
  • Pontos adatokat állítanak elő az eszközök vagy rendszerek?Are devices or systems generating accurate data?
  • Megfelelnek a rendszerek a vállalkozás és a végfelhasználók elvárásainak?Are systems meeting the expectations of both the business and end customers?

A naplózó és monitorozó eszközök általában az alábbi négy összetevőt tartalmazzák:Logging and monitoring tools are typically comprised of the following four components:

  • Rendszerteljesítmény- és idővonal-vizualizációs eszközök a rendszer monitorozására és alapszintű hibaelhárításra.System performance and timeline visualization tools to monitor the system and for basic troubleshooting.
  • Pufferelt adatbetöltés a naplóadatok pufferelésére.Buffered data ingestion, to buffer log data.
  • Hosszú távú tároló a naplóadatok megőrzésére.Persistence store to store log data.
  • Keresési és lekérdezési képességek a naplóadatok megtekintésére és felhasználására a részletes hibaelhárításhoz.Search and query capabilities, to view log data for use in detailed troubleshooting.

A monitorozó rendszerekkel megállapításokat kaphat az IoT-megoldások állapotáról, biztonságáról, stabilitásáról és teljesítményéről illetően.Monitoring systems provide insights into the health, security, and stability, and performance of an IoT solution. Ezek a rendszerek részletesebb betekintést is lehetővé tesznek, rögzítik az összetevők konfigurációváltozásait, és kivonatolt naplóadatokat biztosítanak, amelyek feltárhatnak potenciális biztonsági réseket, javíthatják az incidenskezelési folyamatokat, és segíthetik a rendszer tulajdonosát a problémák elhárításában.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. Az átfogó monitorozási megoldásokban az adatokat le lehet kérdezni adott alrendszerenként, vagy több alrendszer összesítéseként.Comprehensive monitoring solutions include the ability to query information for specific subsystems or aggregating across multiple subsystems.

A monitorozási rendszerek fejlesztésének első lépéseként meg kell határozni a hibátlan működést, a szabályozási megfelelőséget és a naplózási követelményeket.Monitoring system development should begin by defining healthy operation, regulatory compliance, and audit requirements. A gyűjtött metrikák a következők lehetnek:Metrics collected may include:

  • A fizikai és peremhálózati eszközök, valamint infrastruktúra-összetevők által jelentett konfigurációváltozások.Physical devices, edge devices, and infrastructure components reporting configuration changes.
  • Az alkalmazások által jelentett konfigurációváltozások, biztonsági naplók, kérésmennyiségek, válaszidők, hibaarányok és szemétgyűjtési statisztikák a felügyelt nyelveken.Applications reporting configuration changes, security audit logs, request rates, response times, error rates, and garbage collection statistics for managed languages.
  • Az adatbázisok, adatmegőrzési tárolók és gyorsítótárak által jelentett lekérdezési és írási teljesítmények, sémamódosítások, biztonsági naplók, zárolások és holtpontok, indexelési teljesítmény, processzor-, memória- és lemezhasználat.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.
  • A felügyelt szolgáltatások (IaaS, PaaS, SaaS és FaaS) által jelentett állapotmetrikák és konfigurációváltozások, amelyek befolyásolják a függő rendszerek állapotát és teljesítményét.Managed services (IaaS, PaaS, SaaS, and FaaS) reporting health metrics and configuration changes that impact dependent system health and performance.

A monitorozási metrikák vizualizációi felhívják az üzemeltetők figyelmét a rendszer instabilitásaira, és elősegítik az incidensek megoldását.Visualization of monitoring metrics alert operators to system instabilities and facilitate incident response.

Nyomkövetési telemetriaTracing telemetry

A nyomkövetési telemetriával az üzemeltető nyomon követheti egy adott telemetriaadat útját a létrejöttétől kezdve a teljes rendszerben.Tracing telemetry allows an operator to follow the journey of a piece of telemetry from creation through the system. Ez a nyomkövetés a hibák keresésében és elhárításában kap fontos szerepet.Tracing is important for debugging and troubleshooting. Az Azure IoT Hubot és az IoT Hub eszközoldali SDK-it használó IoT-megoldások esetében a követési datagramok a felhőből az eszközre küldött üzenetként keletkezhetnek, amelyek aztán beépülnek a telemetriastreambe.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.

NaplózásLogging

A naplózórendszerek rendkívül fontosak annak megértéséhez, hogy az adott megoldások milyen műveleteket vagy tevékenységeket hajtottak végre, hogy milyen hibák léptek fel, és a hibák javításában is segítséget nyújthatnak.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. A naplók elemzésével megérthetők és orvosolhatók a hibaállapotok, javíthatók a teljesítményjellemzők, és biztosítható a vonatkozó szabályoknak és szabályozásoknak való megfelelőség.Logs can be analyzed to help understand and remedy error conditions, enhance performance characteristics, and ensure compliance with governing rule and regulations.

Bár az egyszerű szöveges naplózás bevezetési költségei alacsonyabbak, a gépek ezt sokkal nehezebben tudják elemezni/olvasni.Though plain-text logging is lower impact on upfront development costs, it is more challenging for a machine to parse/read. Javasoljuk a strukturált naplózás használatát, mivel az így gyűjtött adatok a gépek által is elemezhetők, és emberi olvasásra is alkalmasak.We recommend structured logging be used, as collected information is both machine parsable and human readable. A strukturált naplózás környezeti adatokkal és metaadatokkal egészíti ki a naplóadatokat.Structured logging adds situational context and metadata to the log information. A strukturált naplózásban a tulajdonságok kulcs/érték párokként vagy – a jobb kereshetőség és lekérdezhetőség érdekében – egy rögzített séma szerint formázott elsődleges elemek.In structured logging, properties are first class citizens formatted as key/value pairs, or with a fixed schema, to enhance search and query capabilities.

A DevOps megfontolandó szempontjaiDevOps considerations

Használja az infrastruktúrát kódként (IaC).Use the Infrastructure as code (IaC). A IaC az infrastruktúra (hálózatok, virtuális gépek, terheléselosztó és a kapcsolatok topológiája) felügyelete deklaratív megközelítéssel.IaC is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) with a declarative approach. A sablonokat verziószámmal kell ellátni, és a kiadási folyamat részeként kell szerepelnie.Templates should be versioned and part of the release pipeline. A legmegbízhatóbb üzembe helyezési folyamatok automatizáltak és idempotens.The most reliable deployment processes are automated and idempotent. Az egyik módszer a IoT-erőforrások és az infrastruktúra üzembe helyezéséhez Azure Resource Manager sablon létrehozása.One way is to create Azure Resource Manager template for provisioning the IoT resources and the infrastructure.

Az infrastruktúra üzembe helyezésének automatizálásához használhatja az Azure DevOps Services, a Jenkins vagy más CI/CD megoldásokat.To automate infrastructure deployment, you can use Azure DevOps Services, Jenkins, or other CI/CD solutions. Az Azure Pipelines az Azure DevOps Services része, és automatizált létrehozási, tesztelési és üzembehelyezési feladatokat futtat.Azure Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments.

A következőre való áttérés előtt érdemes megfontolni a számítási feladatok előkészítését a különböző fázisokra való üzembe helyezéssel és az érvényesítések futtatásával. így a frissítéseket szigorúan vezérelt módon leküldheti az éles környezetbe, és csökkentheti a nem várt üzembe helyezési problémákat.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. A kék-zöld üzembe helyezés és a Kanári-kibocsátások ajánlott központi telepítési stratégiák az élő éles környezetek frissítéséhez.Blue-green deployment and Canary releases are recommended deployment strategies for updating live production environments. Érdemes lehet jó visszaállítási stratégiát is megfontolni, ha egy telepítés meghiúsul; Előfordulhat például, hogy automatikusan újratelepít egy korábbi, sikeres telepítést az üzembe helyezési előzményekből, így az Azure CLI-ben a--Reporting-on-Error jelző paraméter jó példa.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.

Vegye fontolóra Azure monitorhasználatával a megoldás figyelését.Consider monitoring your solution by using Azure Monitor. A Azure Monitor az összes Azure-szolgáltatás figyelésének és naplózásának fő forrása, amely diagnosztikai információkat biztosít az Azure-erőforrásokhoz.Azure Monitor is the main source of monitoring and logging for all your Azure services, it provides diagnostics information for Azure resources. Például figyelheti az IoT hub-on belül végrehajtott műveleteket.You can for example, monitor the operations that take place within your IoT hub. Vannak olyan speciális mérőszámok és események, amelyeket Azure Monitor támogat, valamint szolgáltatásokat, sémákat és kategóriákat az Azure diagnosztikai naplóihoz.There are specific metrics and events that Azure Monitor supports, as well as services, schemas, and categories for Azure Diagnostic Logs.

További információ: Microsoft Azure Well-Architected FrameworkDevOps szakasza.For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

Költségekkel kapcsolatos szempontokCost considerations

Általánosságban elmondható, hogy az Azure díjszabási kalkulátorával becsüljük meg a költségeket.In general, use the Azure pricing calculator to estimate costs. További szempontokat a Microsoft Azure Well-Architected-keretrendszerCost szakasza tartalmaz.Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework.

Az ebben a viszonyítási architektúrában használt szolgáltatásokhoz kapcsolódó költségek optimalizálása is lehetséges.There are ways to optimize costs associated the services used in this reference architecture.

Azure IoT HubAzure IoT Hub

Ebben az architektúrában IoT Hub az a Felhőbeli átjáró, amely az eszközökről származó eseményeket gyűjti.In this architecture, IoT Hub is the cloud gateway that ingests events from devices. IoT Hub számlázás a művelet típusától függően változik.IoT Hub billing varies depending on the type of operation. A létrehozás, frissítés, Beszúrás, törlés ingyenes.Create, update, insert, delete are free. Az eszközről a felhőbe és a felhőből az eszközre irányuló üzenetek számlázása sikeres.Successful operations such as device-to-cloud and cloud-to-device messages are charged.

A sikeresen elküldött eszközről a felhőbe irányuló üzenetek 4 KB-os adattömbökben lesznek felszámítva, IoT Hub.Device-to-cloud messages sent successfully are charged in 4-KB chunks on ingress into IoT Hub. Egy 6 KB-os üzenetet például két üzenetként számítunk fel.For example, a 6-KB message is charged as two messages.

A IoT Hub a csatlakoztatott eszközökre vonatkozó állapotinformációkat az eszköz kettős JSON-dokumentumában tárolja.IoT Hub maintains state information about each connected device in a device twin JSON document. Az eszköz kettős dokumentumának beolvasási műveleteiért díjat számítunk fel.Read operations from a device twin document are charged.

IoT Hub két szintet kínál: Alapszintű és standard.IoT Hub offers two tiers: Basic and Standard.

Ha a IoT architektúra kétirányú kommunikációs funkciókat használ, érdemes lehet a standard szintet használni.Consider using the Standard tier if your IoT architecture uses bi-directional communication capabilities. Ez a csomag egy ingyenes kiadást is kínál, amely a legmegfelelőbb tesztelési célokra.This tier also offers a free edition that is most suited for testing purposes.

Ha csak az eszközökről a felhőbe irányuló UNI-irányú kommunikációra van szüksége, használja az alapszintű csomagot, amely olcsóbb.If you only need uni-directional communication from devices to the cloud, use the Basic tier, which is cheaper.

További információ: IoT hub díjszabása.For more information, see IoT Hub Pricing.

Azure Stream AnalyticsAzure Stream Analytics

A Azure Stream Analytics az adatfolyam-feldolgozáshoz és a szabályok kiértékeléséhez használatos.Azure Stream Analytics is used for stream processing and rules evaluation. A Azure Stream Analytics díjszabása a folyamatos átviteli egységek (SU) óránkénti száma, amely az adatok feldolgozásához szükséges számítási, memória-és adatátviteli kapacitást veszi figyelembe.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. IoT Edge-eszközökön futó Azure Stream Analytics számlázása feladatokkal történik.Azure Stream Analytics on IoT Edge is billed per job. A számlázás akkor kezdődik, amikor egy Stream Analytics feladatot telepítenek az eszközökre, függetlenül a feladatok állapotától, a futástól, a sikertelentől vagy a leállítástól.Billing starts when a Stream Analytics job is deployed to devices regardless of the job status, running, failed, or stopped.

További információ a díjszabásról: stream Analytics díjszabása.For more information about pricing, see Stream Analytics pricing.

Azure FunctionsAzure Functions

Azure Functions az adatátalakításra szolgál, miután elérte a IoT Hub.Azure Functions is used to transform data after it reaches the IoT Hub. A javaslat a felhasználási terv használatára vonatkozik, mivel csak a felhasznált számítási erőforrásokért kell fizetnie.From a cost perspective, the recommendation is to use consumption plan because you pay only for the compute resources you use. Minden alkalommal, amikor egy esemény elindítja a függvény végrehajtását, a díjat másodpercenkénti erőforrás-felhasználás alapján számítjuk fel.You are charged based on per-second resource consumption each time an event triggers the execution of the function. Ha több eseményt dolgoz fel egyetlen végrehajtásban vagy kötegben, csökkentheti a költségeket.Processing several events in a single execution or batches can reduce cost.

Azure Logic AppsAzure Logic Apps

Ebben az architektúrában Logic Apps az üzleti folyamatok integrálására szolgál.In this architecture, Logic Apps is used for business process integration.

A Logic apps díjszabása az utólagos elszámolású modellen működik.Logic apps pricing works on the pay-as-you-go model. Az eseményindítók, műveletek és összekötők végrehajtásának mérése minden alkalommal megtörténik, amikor egy logikai alkalmazás fut.Triggers, actions, and connector executions are metered each time a logic app runs. Az összes sikeres és sikertelen művelet, beleértve az eseményindítókat, végrehajtásnak számít.All successful and unsuccessful actions, including triggers, are considered as executions.

A logikai alkalmazás például naponta 1000 üzenetet dolgoz fel.For instance, your logic app processes 1000 messages a day. Egy öt műveletből álló munkafolyamat a $6-nél kisebb lesz.A workflow of five actions will cost less than $6.

További információ: Logic apps díjszabása.For more information, see Logic Apps pricing.

AdattárolásData Storage

Az Azure Blob Storage a leghatékonyabb megoldás a hatékony eléréshez.For cold path storage, Azure Blob Storage is the most cost-effective option.

A meleg elérési út tárolásához érdemes Azure Cosmos DB használni.For warm path storage, consider using Azure Cosmos DB. További információ: Cosmos db díjszabása.For more information, see Cosmos DB pricing.

Következő lépésekNext steps