Azure Load Testing egyéni beépülő modulokkal az Event Hubshoz és az IoT Hubhoz

Megoldási ötletek

Ez a cikk egy megoldási ötletet ismertet. A felhőmérnök ezen útmutató segítségével megjelenítheti az architektúra tipikus implementációjának fő összetevőit. Ez a cikk kiindulási pontként szolgál egy jól megtervezett megoldás megtervezéséhez, amely megfelel a számítási feladat egyedi követelményeinek.

Ez a megoldás útmutatást nyújt az Azure Load Testing szolgáltatás használatához, amely lehetővé teszi Apache JMeter-szkriptek és egyéni beépülő modulok futtatását a felhasználók és eszközök viselkedésének szimulálásához. Ez a megoldás azt is ismerteti, hogyan tervezhet fő teljesítménymutatókat (KPI-ket), és hogyan fejleszthet irányítópultot a terhelésteszt eredményeinek monitorozásához és elemzéséhez egy mintaalkalmazásban az Azure Functions és az Azure Event Hubs használatával. Ez a példa az Event Hubsot használja, de ugyanezt a megközelítést alkalmazhatja az Azure IoT Hubra is, ha az Event Hubs-ügyfelet az IoT Hub-ügyfélre módosítja. Ez a cikk feltételezi, hogy ismeri a JMetert, annak beépülő moduljait és egyéni beépülő moduljait, valamint a Functions és az Event Hubs szolgáltatást.

Az IoT Hub több alapvető összetevőt tartalmaz, mint az Event Hubs, beleértve a partíciókat is. Ezért a cikkben ismertetett terheléstesztelési megközelítés minimális módosításokkal az IoT Hubra is vonatkozik.

Architektúra

A terheléstesztelés elvégzéséhez teszttervre van szükség, amely egy utasításkészlet, amely tájékoztatja a JMetert, hogy mit kell tennie a teszt során. A tesztterv több tesztforgatókönyvet is tartalmazhat, és mindegyik forgatókönyv különböző beállításokkal és konfigurációkkal rendelkezhet. Előfordulhat például, hogy egy olyan forgatókönyvvel rendelkezik, amely egy webalkalmazáshoz hozzáférő egyetlen felhasználót szimulál, egy másik forgatókönyv pedig több felhasználó egyidejű elérését szimulálja ugyanahhoz az alkalmazáshoz.

Töltse le az architektúra Visio-fájlját.

Adatfolyam

Az alábbi adatfolyam az előző diagramnak felel meg:

A szimulált eszköz adatokat küld egy eseményközpontnak egy Terheléstesztelési ügynökön keresztül. Az eszköz bármilyen viselkedése JMeter egyéni beépülő modulokkal szimulálható. A Terheléstesztelési ügynök adatokat küld az eseményközpontnak, miután bármilyen szimulált eszköz egyéni beépülő modulját futtatja.
Az eseményközpont elindít egy Azure-függvényalkalmazást, amely feldolgozza az adatokat, és elküldi azokat más alárendelt szolgáltatásoknak, például az Azure SQL Database-nek és az Azure Digital Twinsnek.
Az Azure Monitor figyeli a függvényalkalmazást és az Event Hubsot.
A Load Testing összegyűjti az adatokat az Azure Monitorból, és megjeleníti azokat egy irányítópulton.

Összetevők

Ez a példa a következő összetevőket használja:

Terheléstesztelés: A terheléstesztelés használatával Apache JMeter-szkripteket és egyéni beépülő modulokat futtathat a felhasználók és az eszközök viselkedésének szimulálásához. A Terheléstesztelés egy webes felületet biztosít a terheléses tesztek kezeléséhez és futtatásához, valamint a folyamat automatizálásához használható API-k készletét. A terheléstesztelés egy teljes mértékben felügyelt szolgáltatás, ami azt jelenti, hogy nem kell kiszolgálókat vagy infrastruktúrát kezelnie. Ebben az architektúrában a Load Testing feltölti a JMeter-szkripteket és az egyéni beépülő modulokat, és ez az a számítás, ahol ezek a szkriptek futnak.
Event Hubs: Az Event Hubs egy felhőalapú eseményfeldolgozó szolgáltatás, amellyel valós időben gyűjtheti, feldolgozhatja és elemezheti a különböző forrásokból származó eseményeket és streamelési adatokat. Az Event Hubs több protokollt is támogat, beleértve az Advanced Message Queuing Protocol (AMQP), a HTTPS, a Kafka protokoll, a Message Queuing Telemetry Transport (MQTT) és az AMQP over WebSocket protokollt. Ez az architektúra eseményalapú, ezért a terheléstesztelés feltölti az eseményeket a számítási feladat betöltéséhez.
IoT Hub: Az IoT Hub egy felhőalapú felügyelt szolgáltatás, amely központi üzenetközpontként szolgál az IoT-alkalmazások és a csatlakoztatott eszközök közötti kommunikációhoz. Több millió eszközt és azok háttérmegoldásait megbízhatóan és biztonságosan csatlakoztathatja. Szinte bármilyen eszköz csatlakoztatható egy IoT Hubhoz. Ezt az architektúrát az IoT Hub használatára módosíthatja úgy, hogy az Event Hubs-ügyfelet az IoT Hub-ügyfélre módosítja.
Azure Functions: A Functions egy kiszolgáló nélküli számítási szolgáltatás, amellyel anélkül futtathat kódot, hogy kiszolgálókat vagy infrastruktúrát kellene kezelnie. Több programozási nyelvet is támogat, beleértve a C#, az F#, a Java, a JavaScript, a PowerShell, a Python és a TypeScript nyelvet. Ez az architektúra a Functionst használja elsődleges számítási szintként. Az Event Hubs eseményadatai aktiválják és kibővítik a függvényalkalmazásokat.
JMeter GUI: A JMeter GUI egy nyílt forráskódú terheléstesztelő eszköz, amelyet elsősorban a webalkalmazások teljesítményének tesztelésére használnak. Más típusú alkalmazások, például SOAP- és REST-webszolgáltatások, FTP-kiszolgálók és adatbázisok tesztelésére is használható.
Azure Monitor: Az Azure Monitor monitorozási és riasztási képességeket biztosít az Azure-erőforrásokhoz. Ezzel monitorozza az alkalmazások és a mögöttes infrastruktúra teljesítményét és állapotát. Ebben az architektúrában az Azure Monitor monitorozza az Azure-infrastruktúra összetevőinek állapotát a terhelésteszt során.

Forgatókönyv részletei

A Terheléstesztelés használatával alkalmazhat egy meglévő Apache JMeter-szkriptet, és bármilyen Azure-erőforráson futtathat terheléstesztet felhőbeli méretekben.

A JMeter lehetővé teszi a tesztelők számára a terheléses tesztek, a stressztesztek és a funkcionális tesztek létrehozását és futtatását. Több felhasználó egyidejű elérését szimulálja egy webalkalmazáshoz, hogy a tesztelők azonosíthassák a lehetséges teljesítménybeli szűk keresztmetszeteket vagy egyéb problémákat, amelyek nagy terhelés esetén merülhetnek fel. A JMeter használatával különböző teljesítménymetrikákat mérhet, például a válaszidőt, az átviteli sebességet és a hibaarányt.

A JMeter grafikus felhasználói felülettel teszi lehetővé a felhasználók számára tesztcsomagok létrehozását, amelyek több különböző beállítással és konfigurációval rendelkező tesztforgatókönyvet is tartalmazhatnak. A tesztelők beépülő modulokkal vagy egyéni kód írásával is testre szabhatják a JMetert. A beépülő modulok segítségével a felhasználók olyan szolgáltatásokkal dolgozhatnak, amelyek nem HTTP protokollokat használnak, például AMQP-t és WebSocketet.

A JMeter számos funkciót és funkciót biztosít a terhelésteszteléshez, de a beépített funkciók nem feltétlenül fedik le a konkrét használati eseteket vagy követelményeket. Egyéni beépülő modulok fejlesztésével a tesztelők új funkciókat adhatnak hozzá, vagy testre szabhatják a meglévő funkciókat, hogy jobban megfeleljenek az igényeiknek.

Létrehozhat például egy egyéni beépülő modult egy adott felhasználói viselkedés szimulálásához vagy reálisabb tesztadatok létrehozásához. Egyéni beépülő modulokat is fejleszthet a JMeter más eszközökkel vagy rendszerekkel való integrálásához, például naplózási és jelentéskészítési eszközökkel, vagy folyamatos integrációs és folyamatos üzembe helyezési (CI/CD) folyamatokkal. Az egyéni beépülő modulok megkönnyítik a tesztelési folyamatot, és megkönnyítik a terheléstesztelés beépítését a teljes szoftverfejlesztési munkafolyamatba. Lehetővé teszik a tesztelők számára, hogy a JMeter-et a saját igényeikhez szabják, és javítsák a terheléstesztelési erőfeszítéseik pontosságát és hatékonyságát.

Ebben a példában egy eszköz egy adott időszak hőmérsékletét és páratartalmat jelez. A példa ezt a viselkedést egy egyéni JMeter beépülő modullal szimulálja. Az egyéni beépülő modul jelenlegi implementációja véletlenszerű adatokat hoz létre egy megadott sablon használatával. A beépülő modul azonban bármilyen lehetséges összetett viselkedést tartalmazhat bármilyen eszköz esetében. Ebben a példában az eszköz elküldi az adatokat egy Azure-beli eseményközpontnak. Az eseményközpont elindít egy Azure-függvényalkalmazást, amely feldolgozza az adatokat, és elküldi azokat más alárendelt szolgáltatásoknak, például az SQL Database-nek. Az Azure Functions az architektúra által tesztelt szolgáltatás. A tesztterv célja az eszköz viselkedésének szimulálása és az adatok küldése az eseményközpontba.

Lehetséges használati esetek

A terheléstesztelés egyéni beépülő modulokkal való használata különböző helyzetekben lehet hasznos, például:

Nem HTTP protokollokat használó alkalmazások teljesítményének tesztelése, például AMQP és WebSocket.
Egyéni protokollt használó alkalmazások teljesítményének tesztelése.
Nem Microsoft SDK-t használó alkalmazások teljesítményének tesztelése.
A felhasználó vagy eszköz viselkedésének egy adott típusának szimulálása.
Reálisabb tesztadatok létrehozása.

Egyéni beépülő modulok

A JMeterben az egyéni beépülő modulok olyan szoftverösszetevők, amelyeket hozzáadhat az alapértelmezett funkciók bővítéséhez. Az egyéni beépülő modulok új funkciókat, függvényeket vagy integrációkat adnak hozzá a JMeterhez. Egyéni beépülő modulokat a Java programozási nyelv és a JMeter beépülő modul fejlesztői készlet (PDK) használatával fejleszthet. A PDK olyan eszközöket és API-kat biztosít, amelyekkel új beépülő modulok hozhatók létre, beleértve a grafikus felhasználói felület elemeit, a figyelőket és a mintavevőket.

Ha egyéni mintavevőt szeretne implementálni az Event Hubshoz a JMeterben, kövesse a JMeter-beépülő modulok terheléstesztelési utasításait. Az egyéni mintavevő implementálása után a JMeter-tesztcsomagban ugyanúgy használhatja a terheléstesztelésben, mint bármely más mintavevőben.

Egy teszttervet egy olyan szálcsoporttal valósíthat meg, amely egy adott forgatókönyv futtatásához szabályozza a szálak számát, például a virtuális felhasználókat és az eszközöket. Minden szálcsoport különböző beállításokkal rendelkezhet a szálak számához, a felfutási időszakhoz, a hurokszámhoz és az időtartamhoz. A szálcsoportok a tesztterv konfigurációjától és az alkalmazás követelményeitől függően szekvenciálisan vagy párhuzamosan is futtathatók. Hozzáadhatja a mintavevőt egy szálcsoporthoz, beállíthatja annak paramétereit, és szükség szerint konfigurálhatja. Az egyéni mintavevők hatékony eszközök lehetnek a JMeterben, amelyekkel összetett forgatókönyveket és kéréseket szimulálhat, amelyeket a beépített mintavevők nem támogatnak.

Apache JMeter-szkript létrehozása egyéni beépülő modullal

Ebben a szakaszban egy JMeter-mintaszkriptet hoz létre egy alkalmazás Event Hubs-beli betöltéséhez.

JMeter-mintatesztszkript létrehozása:

Hozzon létre egy LoadTest.jmx fájlt egy szövegszerkesztőben, és illessze be a következő kódrészletet a fájlba. Ez a szkript 36 virtuális gép terheléstesztét szimulálja, amelyek egyidejűleg eseményeket küldenek egy eseményközpontba. A befejezés 10 percet vesz igénybe.

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
            <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
            <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
            <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
                <boolProp name="LoopController.continue_forever">false</boolProp>
                <intProp name="LoopController.loops">-1</intProp>
            </elementProp>
            <stringProp name="ThreadGroup.num_threads">36</stringProp>
            <stringProp name="ThreadGroup.ramp_time">20</stringProp>
            <boolProp name="ThreadGroup.scheduler">true</boolProp>
            <stringProp name="ThreadGroup.duration">600</stringProp>
            <stringProp name="ThreadGroup.delay"></stringProp>
            <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
             <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
                <!-- Azure Event Hub connection configuration using Managed Identity (see repository for instructions) -->
                <boolProp name="useManagedIdentity">true</boolProp>
                <stringProp name="eventHubNamespace">telemetry-ehn.servicebus.windows.net</stringProp>
                <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
            </com.microsoft.eventhubplugin.EventHubPlugin>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

A com.microsoft.eventhubplugin.EventHubPluginGui és com.microsoft.eventhubplugin.EventHubPlugin implementálása elérhető az Azure-minták között.

A fájlban állítsa be az Event Hubs kapcsolati értékeit a tesztfuttatók hozzárendelt felügyelt identitásával. Az identitásnak írási jogosultsággal kell rendelkeznie az Event Hubs-példányhoz.
A fájlban állítsa a csomópont értékét eventHubName az eseményközpont nevére, például telemetry-data-changed-eh.
Állítsa a liquidTemplateFileName csomópont értékét arra a fájlra, amely az eseményközpontnak küldött üzenetet tartalmazza. Hozzon létre például egy fájlt a következő néven StreamingDataTemplate.liquid :
```
{
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}",
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}
```
Ebben a példában az eseményközpont üzenetének hasznos adatai egy olyan JSON-objektum, amely három tulajdonsággal rendelkezik, MachineId, Temperature, és Humidity. MachineId egy véletlenszerűen létrehozott azonosító, amely 27 karakter hosszú, és TemperatureHumidity véletlenszerű egész szám, amely kisebb, mint 100. Ez a fájl egy folyékony sablon szintaxisa. A Folyékony sablon egy népszerű templating nyelv, amelyet különböző webfejlesztési keretrendszerekben használnak. A folyékony sablonok lehetővé teszik a fejlesztők számára, hogy dinamikus tartalmakat hozzanak létre, amelyek könnyen frissíthetők és módosíthatók. Lehetővé teszik változók, feltételek, hurkok és egyéb dinamikus elemek beszúrását az eseményközpont üzeneteibe. A szintaxis egyszerű, és rengeteg online forrás áll rendelkezésre az első lépésekhez. A folyékony sablonok hatékony és rugalmas módot biztosítanak dinamikus, testreszabható üzenetek létrehozására.
Mentse és zárja be a fájlt.

Fontos

A JMeter-szkriptben ne adjon meg semmilyen személyes adatot a mintavevő nevére. A mintavevők nevei megjelennek a terheléstesztelési teszt eredményeinek irányítópultján. Egy folyékony sablon mintája és a JMeter-szkriptfájl letölthető az Azure-mintákból.

Az egyéni beépülő modul frissítése az Event Hubsból az IoT Hubra

Az egyéni beépülő modul elsődleges célerőforrásként az Event Hubsot használja. A következő konfiguráció az Event Hubs SDK-ügyfélbeállítása:

EventHubProducerClient producer = null;
EventHubClientBuilder producerBuilder = new EventHubClientBuilder();

producerBuilder.credential(getEventHubNamespace(), getEventHubName(), new DefaultAzureCredentialBuilder().build());
producer = producerBuilder.buildProducerClient();

EventDataBatch batch = producer.createBatch(new CreateBatchOptions());
batch.tryAdd(new EventData(msg));
producer.send(batch);

Az alábbi példa bemutatja, hogyan használhatja újra ugyanazt a megoldást, hogyan adhat hozzá IoT-függőségeket, és hogyan módosíthatja az SDK-ügyfelet az IoT Hub használatára:

IotHubServiceClientProtocol protocol = IotHubServiceClientProtocol.AMQPS;
ServiceClient client = new ServiceClient(getIoTHostName(), new DefaultAzureCredentialBuilder().build(), protocol);
client.open();

Message message = new Message(msg);
client.send(getDeviceName(), message);

client.close();

A terhelési teszt futtatása az új beépülő modullal

Amikor a Terheléstesztelés elindítja a terheléstesztet, először üzembe helyezi a JMeter-szkriptet az összes többi fájllal együtt a tesztmotor-példányokon. A teszt futtatása előtt lépjen a paraméter lapra a szükséges paraméterek definiálásához és beállításához. További információ: Terhelésteszt testreszabása Apache JMeter beépülő modulokkal és terhelésteszteléssel.

Teljesítménytesztelés beállítása a környezethez

Fontos, hogy a teljesítménytesztelés során a tesztkörnyezet azonos legyen az éles környezettel. Ez a példa a következő környezetet használja a teljesítményteszteléshez a rendszer kapacitásának és teljesítményének jobb megértéséhez.

Szolgáltatás	Konfiguráció
Event Hubs	Prémium egy feldolgozóegységtel
Azure Functions	Linux prémium csomaggal (EP1) – 210 ACU, 3,5 GB memória és 1 vCPU-val egyenértékű Standard_D1_v2
Régió	USA keleti régiója

A megfelelő szolgáltatási szint kiválasztása bármely Azure-szolgáltatáshoz, beleértve az Event Hubsot és az Azure Functionst is, összetett folyamat, és számos tényezőtől függ. További információkért tekintse meg az Event Hubs díjszabását és a Functions díjszabását.

KpI-k tervezése teljesítményteszteléshez

Mielőtt kpi-ket tervezhet a teljesítményteszteléshez, meg kell határoznia az üzleti követelményeket és a rendszerarchitektúrát. Az üzleti követelményekből megtudhatja, hogy mely KPI-ket, például a válaszidőt, az átviteli sebességet vagy a hibaarányt szeretné mérni. A rendszerarchitektúra bemutatja, hogyan tesztelheti az egyes összetevők, például webkiszolgálók, adatbázisok vagy API-k teljesítményét. Emellett segít kiválasztani a legjobb teljesítménytesztelési stratégiát, például a terheléstesztelést, a stressztesztelést vagy az állóképesség-tesztelést.

Ez a példa a következő üzleti követelményekkel rendelkezik:

A rendszer másodpercenként 1000 kérést képes kezelni.
A rendszer megbízhatósága magasabb, mint 0,99.
A rendszer 1000 egyidejű, telemetriai adatokat tartalmazó eszközt képes kezelni.
A rendszer maximális kapacitását a támogatott eszközök száma alapján adhatja meg. A rendszer például 1000 egyidejű eszközt támogat az aktuális kapacitás háromszorosával.

Annak méréséhez, hogy a rendszer megfelel-e ezeknek a követelményeknek, a teljesítményteszteléshez a következő KPI-ket használhatja:

KPI	Leírás
RPS	Másodpercenkénti kérelmek egy eseményközponthoz
BETÖLTÉS	Az eseményközpontnak a teljesítménytesztelés során küldött terhelések vagy kérések száma
integrációs modul	Függvényhívások vagy betöltési sebességek száma
RT	Az Azure Functions futási idejének átlagos időtartama
AMU	Az Azure Functions átlagos memóriahasználata
SR	Az összes függvényalkalmazás-meghívás sikerességi aránya
ARS	Az alsóbb rétegbeli szolgáltatások válaszidejének átlaga olyan szolgáltatások esetében, mint az SQL Server vagy a mikroszolgáltatás
DF	Függőségi hibák száma, beleértve a belső függvényalkalmazás hibáit
MRPS	Maximális RPS hátralék nélkül az eseményközpontban (rendszerkapacitás)

KpI-k mérése

A KPI-k méréséhez teljesítménytesztelési stratégiával kell rendelkeznie. A stratégia meghatározza az egyes összetevők teljesítménytesztelési megközelítését. Ez a példa a következő teljesítménytesztelési stratégiát használja.

Event Hubs: Az eseményközpont teljesítménytesztelési módszere, hogy sok üzenetet küld az eseményközpontnak, majd méri az RPS-t és a LOAD-t. Az RPS az eseményközpontba másodpercenként küldött üzenetek száma. A TERHELÉS az eseményközpontnak a teljesítménytesztelés során küldött üzenetek teljes száma. A terheléstesztelés képes mérni az RPS-t és a LOAD-t.
Azure Functions: A Functions teljesítménytesztelési módszere az alábbi metrikák mérése.
- integrációs modul
- RT
- AMU
- SR
- ARS
- DF

Az Azure Monitor képes az AMU, az ARS és a DF mérésére, de ir, RT vagy SR nem. Ha az Azure Monitor használatával szeretné mérni a KPI-ket, engedélyezze az Application Insightst az Azure Functionshez. További információ: Application Insights-integráció engedélyezése.

Az Azure Monitor engedélyezése után az alábbi lekérdezésekkel mérheti a KPI-ket:

Infravörös: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Azure Monitor-irányítópult minta

Az alábbi képen az Azure Monitor irányítópultjának egy mintája látható. Az Azure Functions KPI-jait jeleníti meg az előző lekérdezések alapján.

Közreműködők

A Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.

Fő szerzők:

Mahdi Setayesh | Fő szoftvermérnök
Oscar Fimbres | Vezető szoftvermérnök

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

Visszajelzés

Hasznosnak találta ezt az oldalt?

Utolsó frissítés időpontja: 2026-04-21