Python-Featureverwaltung
Die Python-Featureverwaltungsbibliothek bietet eine Möglichkeit, Anwendungsfunktionen basierend auf Featureflags zu entwickeln und verfügbar zu machen. Sobald ein neues Feature entwickelt wurde, haben viele Anwendungen spezielle Anforderungen, z. B. wann das Feature aktiviert werden soll und unter welchen Bedingungen. Diese Bibliothek bietet eine Möglichkeit, diese Beziehungen zu definieren, und lässt sich auch in gängige Python-Codemuster integrieren, um diese Features verfügbar zu machen.
Featureflags bieten eine Möglichkeit für Python-Anwendungen, Features dynamisch zu aktivieren oder zu deaktivieren. Entwickler können Featureflags in einfachen Anwendungsfällen wie Bedingungsanweisungen verwenden.
Hier sind einige der Vorteile der Verwendung der Python-Featureverwaltungsbibliothek:
Eine allgemeine Konvention für die Featureverwaltung
Niedrige Einstiegsbarriere
- Unterstützung für das Einrichten von JSON-Featureflags
Verwaltung der Featureflaglebensdauer
- Konfigurationswerte können sich in Echtzeit ändern; Featurekennzeichnungen können für die gesamte Anforderung konsistent sein
Behandlung einfacher bis komplexer Szenarien
- Aktivieren/Deaktivieren von Features durch deklarative Konfigurationsdatei
- Dynamische Auswertung des Funktionsstatus basierend auf dem Aufruf an den Server
Die Python-Featureverwaltungsbibliothek ist Open Source. Weitere Informationen finden Sie im GitHub-Repository.
Featureflags
Featurekennzeichnungen bestehen aus zwei Teilen, einem Namen und einer Liste von Featurefiltern, die zum Aktivieren des Features verwendet werden.
Featurefilter
Featurefilter definieren ein Szenario, für das ein Feature aktiviert werden soll. Wenn ein Feature ausgewertet wird, egal ob es aktiviert oder deaktiviert ist, wird die Liste der Featurefilter durchlaufen, bis einer der Filter entscheidet, dass das Feature aktiviert werden soll. An diesem Punkt gilt das Feature als aktiviert und der Durchlauf der Featurefilter endet. Wenn kein Featurefilter angibt, dass das Feature aktiviert werden soll, gilt es als deaktiviert.
Beispielsweise könnte ein Microsoft Edge-Browserfeaturefilter entworfen werden. Dieser Featurefilter aktiviert alle daran angefügten Features, solange eine HTTP-Anforderung von Microsoft Edge stammt.
Featureflagkonfiguration
Ein Python-Wörterbuch wird zum Definieren von Featureflags verwendet. Das Wörterbuch besteht aus Featurenamen als Schlüssel und Featureflagobjekte als Werte. Das Featureflagobjekt ist ein Wörterbuch, das einen conditions-Schlüssel enthält, der wiederum den client_filters-Schlüssel enthält. Der Schlüssel client_filters ist eine Liste der Featurefilter, mit denen ermittelt wird, ob das Feature aktiviert werden soll.
Featureflagdeklaration
Die Featureverwaltungsbibliothek unterstützt JSON als Featureflagquelle. Nachfolgend finden Sie ein Beispiel für das Format, das zum Einrichten von Featureflags in einer JSON-Datei verwendet wird.
{
"feature_management": {
"feature_flags": [
{
"id": "FeatureT",
"enabled": "true"
},
{
"id": "FeatureU",
"enabled": "false"
},
{
"id": "FeatureV",
"enabled": "true",
"conditions": {
"client_filters": [
{
"name": "Microsoft.TimeWindow",
"parameters": {
"Start": "Wed, 01 May 2019 13:59:59 GMT",
"End": "Mon, 01 Jul 2019 00:00:00 GMT"
}
}
]
}
}
]
}
}
Der feature_management-Abschnitt des JSON-Dokuments wird konventionsspezifisch zum Laden von Featurekennzeichnungseinstellungen verwendet. Der Abschnitt feature_flags ist eine Liste der Featureflags, die in die Bibliothek geladen werden. Im Abschnitt oben sehen wir drei verschiedene Features. Features definieren ihre Featurefilter mithilfe der client_filters-Eigenschaft in conditions. In den Featurefiltern für FeatureT sehen wir, dass enabled ohne definierte Filter aktiviert ist, was dazu führt, dass FeatureT immer true zurückgibt. FeatureU ist identisch mit FeatureT, aber mit enabled gleich false, was dazu führt, dass das Feature immer false zurückgibt. FeatureV gibt einen Featurefilter mit dem Namen Microsoft.TimeWindow an. FeatureV ist ein Beispiel für einen konfigurierbaren Featurefilter. Wir können im Beispiel sehen, dass der Filter über eine parameters-Eigenschaft verfügt. Die Eigenschaft parameters wird verwendet, um den Filter zu konfigurieren. In diesem Fall werden die Start- und Endzeiten für das zu aktive Feature konfiguriert.
Das detaillierte Schema des feature_management-Abschnitts finden Sie hier.
Erweitert: Die Verwendung des Doppelpunkts ":" ist in Featurekennzeichnungsnamen verboten.
On/Off-Deklaration
Der folgende Codeausschnitt veranschaulicht eine alternative Möglichkeit zum Definieren eines Features, das für Ein-/Aus-Features verwendet werden kann.
{
"feature_management": {
"feature_flags": [
{
"id": "FeatureT",
"enabled": "true"
},
{
"id": "FeatureX",
"enabled": "false"
}
]
}
}
Requirement_type
Die requirement_type-Eigenschaft einer Featurekennzeichnung wird verwendet, um zu bestimmen, ob die Filter Any- oder All-Logik zum Auswerten des Status eines Features verwenden sollen. Wenn requirement_type nicht angegeben ist, wird der Standardwert Any.
Anybedeutet, dass nur ein Filter als „true“ ausgewertet werden muss, damit das Feature aktiviert wird.Allbedeutet, dass jeder Filter als „true“ ausgewertet werden muss, damit das Feature aktiviert wird.
Eine requirement_type von All ändert das Traversal. Wenn keine Filter vorhanden sind, ist das Feature deaktiviert. Anschließend werden die Featurefilter durchlaufen, bis einer der Filter entscheidet, dass das Feature deaktiviert werden soll. Wenn kein Filter angibt, dass das Feature deaktiviert werden soll, wird es als aktiviert betrachtet.
{
"feature_management": {
"feature_flags": [
{
"id": "FeatureW",
"enabled": "true",
"conditions": {
"requirement_type": "All",
"client_filters": [
{
"name": "Microsoft.TimeWindow",
"parameters": {
"Start": "Wed, 01 May 2019 13:59:59 GMT",
"End": "Mon, 01 Jul 2019 00:00:00 GMT"
}
},
{
"name": "Percentage",
"parameters": {
"Value": "50"
}
}
]
}
},
]
}
}
Im obigen Beispiel gibt FeatureW eine requirement_type von All an, was bedeutet, dass alle Filter als „true“ ausgewertet werden müssen, damit das Feature aktiviert werden kann. In diesem Fall ist das Feature für 50 % der Benutzer im angegebenen Zeitfenster aktiviert.
Verbrauch
Die grundlegende Form der Featureverwaltung überprüft, ob eine Featurekennzeichnung aktiviert ist und führt dann Aktionen basierend auf dem Ergebnis aus. Der Status eines Featureflags wird über die Methode is_enabled von FeatureManager überprüft.
…
feature_manager = FeatureManager(feature_flags)
…
if feature_manager.is_enabled("FeatureX"):
# Do something
Die für FeatureManager bereitgestellten Featureflags (feature_flags) können entweder AzureAppConfigurationProvider oder ein Wörterbuch mit Featureflags sein.
Implementieren eines Featurefilters
Das Erstellen eines Featurefilters bietet eine Möglichkeit, Features basierend auf von Ihnen definierten Kriterien zu aktivieren. Um einen Featurefilter zu implementieren, muss die FeatureFilter-Schnittstelle implementiert werden. FeatureFilter hat eine einzelne Methode mit dem Namen evaluate. Wenn ein Feature angibt, dass es für einen Featurefilter aktiviert werden kann, wird die evaluate-Methode aufgerufen. Wenn evaluate true zurückgibt, bedeutet dies, dass das Feature aktiviert werden soll.
Der folgende Codeausschnitt veranschaulicht das Hinzufügen eines benutzerdefinierten Featurefilters MyCustomFilter.
feature_manager = FeatureManager(feature_flags, feature_filters=[MyCustomFilter()])
Featurefilter werden registriert, indem sie beim Erstellen von FeatureManager für die Eigenschaft feature_filters bereitgestellt werden. Wenn ein benutzerdefinierter Featurefilter Kontext benötigt, können sie beim Aufrufen von is_enabled mithilfe von kwargs übergeben werden.
Filteraliasattribut
Wenn ein Featurefilter für ein Featureflag registriert ist, wird der Name des Filters standardmäßig als Alias verwendet.
Der Bezeichner für den Featurefilter kann mithilfe von @FeatureFilter.alias("MyFilter") überschrieben werden. Ein Featurefilter kann mit diesem Attribut versehen werden, um den Namen zu deklarieren, der in der Konfiguration verwendet werden soll, um auf diesen Featurefilter in einer Featurekennzeichnung zu verweisen.
Fehlende Featurefilter
Wenn ein Feature so konfiguriert ist, dass es für einen bestimmten Featurefilter aktiviert ist und dieser Featurefilter nicht registriert ist, wird eine Ausnahme vom Typ ValueError ausgelöst, wenn das Feature ausgewertet wird.
Integrierte Featurefilter
Es gibt zwei Featurefilter, die im FeatureManagement-Paket enthalten sind: TimeWindowFilter und TargetingFilter.
Jeder der integrierten Featurefilter verfügt über eigene Parameter. Hier ist die Liste der Featurefilter zusammen mit Beispielen.
Microsoft.TimeWindow
Dieser Filter bietet die Möglichkeit, ein Feature basierend auf einem Zeitfenster zu aktivieren. Wenn nur End angegeben ist, wird das Feature bis zu diesem Zeitpunkt aktiviert. Wenn nur Start angegeben ist, wird das Feature zu allen Zeitpunkten berücksichtigt.
"client_filters": [
{
"name": "Microsoft.TimeWindow",
"parameters": {
"Start": "Wed, 01 May 2019 13:59:59 GMT",
"End": "Mon, 01 Jul 2019 00:00:00 GMT"
}
}
]
Microsoft.Targeting
Dieser Filter bietet die Möglichkeit, ein Feature für eine Zielgruppe zu aktivieren. Eine ausführliche Erläuterung der Zielbestimmung wird im folgenden Abschnitt zur Zielbestimmung erläutert. Die Filterparameter enthalten ein Audience-Objekt, das Benutzer, Gruppen, ausgeschlossene Benutzer/Gruppen und einen Standardprozentsatz der Benutzerbasis beschreibt, die Zugriff auf das Feature haben sollen. Jedes Gruppenobjekt, das im Groups-Abschnitt aufgeführt ist, muss auch angeben, welcher Prozentsatz der Mitglieder der Gruppe Zugriff haben soll. Wenn ein Benutzer im Exclusion-Abschnitt angegeben wird, entweder direkt oder wenn sich der Benutzer in einer ausgeschlossenen Gruppe befindet, ist das Feature deaktiviert. Andernfalls, wenn ein Benutzer direkt im Users-Abschnitt angegeben wird, oder wenn der Benutzer den Prozentsatz einer der Gruppenrollouts enthält, oder wenn der Benutzer in den Standardrollout-Prozentsatz fällt, wird dieses Feature aktiviert.
"client_filters": [
{
"name": "Microsoft.Targeting",
"parameters": {
"Audience": {
"Users": [
"Jeff",
"Alicia"
],
"Groups": [
{
"Name": "Ring0",
"RolloutPercentage": 100
},
{
"Name": "Ring1",
"RolloutPercentage": 50
}
],
"DefaultRolloutPercentage": 20,
"Exclusion": {
"Users": [
"Ross"
],
"Groups": [
"Ring2"
]
}
}
}
}
]
Zielbestimmung
Die Zielbestimmung ist eine Featureverwaltungsstrategie, mit der Entwickler neue Features schrittweise für ihre Benutzerbasis bereitstellen können. Die Strategie basiert auf dem Konzept der Zielgruppenadressierung einer Gruppe von Benutzern, die als Zielgruppe bezeichnet werden. Eine Benutzergruppe besteht aus bestimmten Benutzern, Gruppen, ausgeschlossenen Benutzern/Gruppen und einem bestimmten Prozentsatz der gesamten Benutzerbasis. Die Gruppen, die in der Zielgruppe enthalten sind, können weiter in Prozentsätze ihrer Gesamtmitglieder unterteilt werden.
Die folgenden Schritte veranschaulichen ein Beispiel für ein progressives Rollout für ein neues Feature „Beta“:
- Individuelle Benutzer Jeff und Alicia erhalten Zugriff auf die Betaversion
- Ein anderer Benutzer, Mark, fordert die Anmeldung an und wird aufgenommen.
- Zwanzig Prozent einer Gruppe, die als „Ring1“-Benutzer bezeichnet wird, sind in der Betaversion enthalten.
- Die Anzahl der in der Betaversion enthaltenen „Ring1“-Benutzer wird auf 100 Prozent erhöht.
- Fünf Prozent der Benutzerbasis sind in der Betaversion enthalten.
- Der Rollout-Prozentsatz wird auf 100 Prozent erhöht, und das Feature wird vollständig eingeführt.
Diese Strategie für das Rollout eines Features ist über den enthaltenen Microsoft.Targeting-Featurefilter in die Bibliothek integriert.
Zielgruppenadressierung eines Benutzers
Ein Benutzer kann entweder direkt im is_enabled-Aufruf angegeben werden, oder der Benutzer und die optionale Gruppe werden mithilfe von TargetingContext angegeben.
# Directly specifying the user
result = is_enabled(feature_flags, "test_user")
# Using a TargetingContext
result = is_enabled(feature_flags, TargetingContext(user_id="test_user", groups=["Ring1"]))
Zielausschluss
Beim Definieren einer Zielgruppe können Benutzer und Gruppen von der Zielgruppe ausgeschlossen werden. Ausschlüsse sind nützlich, wenn ein Feature für eine Gruppe von Benutzern eingeführt wird, aber einige Benutzer oder Gruppen aus dem Rollout ausgeschlossen werden müssen. Der Ausschluss wird durch Hinzufügen einer Liste von Benutzern und Gruppen zur Exclusion-Eigenschaft der Benutzergruppe definiert.
"Audience": {
"Users": [
"Jeff",
"Alicia"
],
"Groups": [
{
"Name": "Ring0",
"RolloutPercentage": 100
}
],
"DefaultRolloutPercentage": 0
"Exclusion": {
"Users": [
"Mark"
]
}
}
Im obigen Beispiel ist das Feature für Benutzer mit dem Namen Jeff und Alicia aktiviert. Es ist auch für Benutzer in der Gruppe mit dem Namen Ring0 aktiviert. Wenn der Benutzer jedoch Mark benannt ist, ist das Feature deaktiviert, unabhängig davon, ob er sich in der Gruppe Ring0 befindet oder nicht. Ausschlüsse haben Vorrang vor dem Rest des Zielfilters.
Varianten
Wenn einer Anwendung neue Features hinzugefügt werden, kann es vorkommen, dass ein Feature über mehrere verschiedene vorgeschlagene Entwurfsoptionen verfügt. Eine gängige Lösung für die Entscheidung für ein Design ist eine Form von A/B-Tests. A/B-Tests umfassen das Bereitstellen einer anderen Version des Features für verschiedene Segmente der Benutzerbasis und das Auswählen einer Version basierend auf der Benutzerinteraktion. In dieser Bibliothek wird diese Funktionalität aktiviert, indem verschiedene Konfigurationen eines Features mit Varianten dargestellt werden.
Varianten aktivieren eine Featurekennzeichnung, um mehr als eine einfache Ein-/Aus-Kennzeichnung zu werden. Eine Variante stellt einen Wert einer Featurekennzeichnung dar, die eine Zeichenfolge, eine Zahl, ein boolescher Wert oder sogar ein Konfigurationsobjekt sein kann. Ein Featureflag, das Varianten deklariert, sollte definieren, unter welchen Umständen jede Variante verwendet werden soll, was im Abschnitt Zuweisen von Varianten ausführlicher behandelt wird.
class Variant:
def __init__(self, name: str, configuration: Any):
self._name = name
self._configuration = configuration
@property
def name(self) -> str:
"""
The name of the variant.
:rtype: str
"""
return self._name
@property
def configuration(self) -> Any:
"""
The configuration of the variant.
:rtype: Any
"""
return self._configuration
Abrufen von Varianten
Für jedes Feature kann eine Variante mithilfe der get_variant-Methode von FeatureManager abgerufen werden.
…
variant = print(feature_manager.get_variant("TestVariants", TargetingContext(user_id="Adam"))
variantConfiguration = variant.configuration;
// Do something with the resulting variant and its configuration
Die zurückgegebene Variante hängt vom aktuell ausgewerteten Benutzer ab, und diese Informationen werden aus einer Instanz von TargetingContext abgerufen.
Deklaration von Variantenfeatureflags
Im Vergleich zu normalen Featureflags weisen Variantenfeatureflags zwei zusätzliche Eigenschaften auf: variants und allocation. Die variants-Eigenschaft ist ein Array, das die für dieses Feature definierten Varianten enthält. Die allocation-Eigenschaft definiert, wie diese Varianten für das Feature zugewiesen werden sollen. Genau wie beim Deklarieren normaler Featureflags können Sie Variantenfeatureflags in einer JSON-Datei einrichten. Hier sehen Sie ein Beispiel für ein Variantenfeatureflag.
{
"feature_management": {
"feature_flags": [
{
"id": "MyVariantFeatureFlag",
"enabled": true,
"allocation": {
"default_when_enabled": "Small",
"group": [
{
"variant": "Big",
"groups": [
"Ring1"
]
}
]
},
"variants": [
{
"name": "Big"
},
{
"name": "Small"
}
]
}
]
}
}
Definieren von Varianten
Jede Variante verfügt über zwei Eigenschaften: einen Namen und eine Konfiguration. Der Name wird verwendet, um auf eine bestimmte Variante zu verweisen, und die Konfiguration ist der Wert dieser Variante. Die Konfiguration kann mithilfe der Eigenschaft configuration_value festgelegt werden. configuration_value ist eine Inlinekonfiguration, die ein Zeichenfolgen-, Zahlen-, boolesches oder Konfigurationsobjekt sein kann. Wenn configuration_value nicht angegeben wird, ist die Eigenschaft Configuration der zurückgegebenen Variante None.
Für jedes Feature unter der variants-Eigenschaft wird eine Liste aller möglichen Varianten definiert.
{
"feature_management": {
"feature_flags": [
{
"id": "MyVariantFeatureFlag",
"variants": [
{
"name": "Big",
"configuration_value": {
"Size": 500
}
},
{
"name": "Small",
"configuration_value": {
"Size": 300
}
}
]
}
]
}
}
Zuweisen von Varianten
Der Prozess der Zuordnung der Varianten eines Features wird durch die allocation-Eigenschaft des Features bestimmt.
"allocation": {
"default_when_enabled": "Small",
"default_when_disabled": "Small",
"user": [
{
"variant": "Big",
"users": [
"Marsha"
]
}
],
"group": [
{
"variant": "Big",
"groups": [
"Ring1"
]
}
],
"percentile": [
{
"variant": "Big",
"from": 0,
"to": 10
}
],
"seed": "13973240"
},
"variants": [
{
"name": "Big",
"configuration_value": "500px"
},
{
"name": "Small",
"configuration_value": "300px"
}
]
Die allocation-Einstellung eines Features weist die folgenden Eigenschaften auf:
| Eigenschaft | Beschreibung |
|---|---|
default_when_disabled |
Gibt an, welche Variante verwendet werden soll, wenn eine Variante angefordert wird, während das Feature als deaktiviert gilt. |
default_when_enabled |
Gibt an, welche Variante verwendet werden soll, wenn eine Variante angefordert wird, während das Feature als aktiviert gilt und dem Benutzer keine andere Variante zugewiesen wurde. |
user |
Gibt eine Variante und eine Liste von Benutzern an, denen diese Variante zugewiesen werden soll. |
group |
Gibt eine Variante und eine Liste von Gruppen an. Die Variante wird zugewiesen, wenn sich der Benutzer in mindestens einer der Gruppen befindet. |
percentile |
Gibt eine Variante und einen Prozentbereich an, in den der berechnete Prozentsatz des Benutzers passt, damit diese Variante zugewiesen werden soll. |
seed |
Der Wert, auf dem prozentuale Berechnungen für percentile basieren. Die prozentuale Berechnung für einen bestimmten Benutzer ist für alle Features gleich, wenn derselbe seed-Wert verwendet wird. Wenn kein seed angegeben wird, wird basierend auf dem Featurenamen ein Standardnamenswert erstellt. |
Wenn das Feature nicht aktiviert ist, weist der Feature-Manager dem aktuellen Benutzer die als default_when_disabled markierte Variante zu, die in diesem Fall Small ist.
Wenn das Feature aktiviert ist, überprüft der Feature-Manager die Zuweisungen user, group und percentile, um eine Variante zuzuweisen. Wenn der ausgewertete Benutzer in der Gruppe mit dem Namen Ring1 Marsha benannt wird oder der Benutzer zwischen das Quantil 0 und 10 fällt, wird dem Benutzer die angegebene Variante zugewiesen. In diesem Fall würden all zugewiesenen Benutzer die Variante Big zurückgeben. Wenn keine dieser Zuordnungen übereinstimmt, wird dem Benutzer die default_when_enabled-Variante zugewiesen, die Small ist.
Die Zuordnungslogik ähnelt dem Microsoft.Targeting-Featurefilter, aber es gibt einige Parameter, die in der Zielbestimmung vorhanden sind, die nicht in der Zuordnung enthalten sind, und umgekehrt. Die Ziel- und Zuordnungsergebnisse hängen nicht zusammen.
Überschreiben des aktivierten Zustands mit einer Variante
Sie können Varianten verwenden, um den aktivierten Status einer Featurekennzeichnung außer Kraft zu setzen. Die Überschreibung bietet Varianten die Möglichkeit, die Auswertung eines Featureflags zu erweitern. Wenn is_enabled bei einem Flag mit Varianten aufgerufen wird, überprüft der Featureverwalter, ob die dem aktuellen Benutzer zugewiesene Variante so konfiguriert ist, dass sie das Ergebnis überschreibt. Die Überschreibung erfolgt mithilfe der optionalen Varianteneigenschaft status_override. Diese Eigenschaft ist standardmäßig auf None festgelegt, was bedeutet, dass die Variante keine Auswirkungen darauf hat, ob die Kennzeichnung als aktiviert oder deaktiviert gilt. Wenn Sie status_override auf Enabled festlegen, kann die Variante bei Auswahl eine zu aktivierende Kennzeichnung außer Kraft setzen. Das Festlegen von status_override auf Disabled bietet die entgegengesetzte Funktionalität, wodurch die Kennzeichnung deaktiviert wird, wenn die Variante ausgewählt wird. Ein Feature mit einem enabled-Status von false kann nicht außer Kraft gesetzt werden.
Wenn Sie ein Featureflag mit binären Varianten verwenden, kann die status_override-Eigenschaft hilfreich sein. Sie können APIs wie is_enabled in Ihrer Anwendung weiterhin verwenden, während Sie von den neuen Features profitieren, die mit Varianten einhergehen, z. B. Perzentilzuweisung und Seed.
{
"id": "MyVariantFeatureFlag",
"enabled": true,
"allocation": {
"percentile": [
{
"variant": "On",
"from": 10,
"to": 20
}
],
"default_when_enabled": "Off",
"seed": "Enhanced-Feature-Group"
},
"variants": [
{
"name": "On"
},
{
"name": "Off",
"status_override": "Disabled"
}
]
}
Im obigen Beispiel ist das Feature immer aktiviert. Wenn sich der aktuelle Benutzer im berechneten Quantilbereich von 10 bis 20 befindet, wird die On-Variante zurückgegeben. Andernfalls wird die Off-Variante zurückgegeben und da status_override gleich Disabled ist, wird das Feature jetzt als deaktiviert betrachtet.
Telemetrie
Wenn eine Featurekennzeichnungsänderung bereitgestellt wird, ist es häufig wichtig, ihre Auswirkungen auf eine Anwendung zu analysieren. Hier sind beispielsweise einige Fragen, die auftauchen können:
- Sind meine Kennzeichnungen wie erwartet aktiviert/deaktiviert?
- Erhalten bestimmte Benutzer den Zugriff auf ein bestimmtes Feature wie erwartet?
- Welche Variante sieht ein bestimmter Benutzer?
Diese Fragen können durch die Emission und Analyse von Auswertungsereignissen von Featurekennzeichnungen beantwortet werden. Diese Bibliothek aktiviert optional AzureMonitor, um während der Auswertung des Featureflags Ablaufverfolgungstelemetriedaten über OpenTelemetry zu erzeugen.
Aktivieren der Telemetrie
Standardmäßig werden keine Telemetriekennzeichnungen ausgegeben. Um Telemetrie für ein bestimmtes Featureflag zu veröffentlichen, MUSS das Flag deklarieren, dass es für die Telemetrieausgabe aktiviert ist.
Bei Featureflags, die in JSON definiert sind, erfolgt die Aktivierung mithilfe der telemetry-Eigenschaft.
{
"feature_management": {
"feature_flags": [
{
"id": "MyFeatureFlag",
"enabled": true,
"telemetry": {
"enabled": true
}
}
]
}
}
Der obige Codeschnipsel definiert ein Featureflag namens MyFeatureFlag, das für Telemetrie aktiviert ist. Die enabled-Eigenschaft des telemetry-Objekts ist auf true festgelegt. Der Wert der enabled-Eigenschaft muss true sein, um Telemetrie für die Kennzeichnung zu veröffentlichen.
Der telemetry-Abschnitt einer Featurekennzeichnung weist die folgenden Eigenschaften auf:
| Eigenschaft | Beschreibung |
|---|---|
enabled |
Gibt an, ob Telemetrie für die Featurekennzeichnung veröffentlicht werden soll. |
metadata |
Eine Sammlung von Schlüsselwertpaaren, die als Wörterbuch modelliert werden, die verwendet werden können, um benutzerdefinierte Metadaten zur Featurekennzeichnung an Auswertungsereignisse anzufügen. |
Darüber hinaus muss beim Erstellen von FeatureManager ein Rückruf registriert werden, um Telemetrieereignisse zu behandeln. Dieser Rückruf wird aufgerufen, wenn ein Featureflag ausgewertet wird und Telemetrie für dieses Flag aktiviert ist.
feature_manager = FeatureManager(feature_flags, on_feature_evaluated=publish_telemetry)
Application Insights-Telemetrie
Die Featureverwaltungsbibliothek bietet einen integrierten Telemetriedatenherausgeber, der Auswertungsdaten des Featureflags an Application Insights sendet. Um Application Insights zu aktivieren, kann die Featureverwaltungsbibliothek mit Azure Monitor über pip install FeatureManagement[AzureMonitor] installiert werden. Mit diesem Befehl wird das azure-monitor-events-extension-Paket installiert, mit dem Telemetriedaten mithilfe von OpenTelemetry an Application Insights übermittelt werden.
Hinweis
Das azure-monitor-events-extension-Paket fügt die Telemetrie nur der OpenTelemetry-Pipeline hinzu. Die Registrierung von Application Insights ist weiterhin erforderlich.
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor(
connection_string="InstrumentationKey=00000000-0000-0000-0000-000000000000"
)
Benutzerdefinierter Telemetriedatenherausgeber
Da es sich bei dem Telemetrierückruf um eine Funktion handelt, kann sie angepasst werden, um Telemetrie an jedem gewünschten Ziel zu veröffentlichen. Telemetriedaten können etwa in einem Protokollierungsdienst, einer Datenbank oder einem benutzerdefinierten Telemetriedienst veröffentlicht werden.
Wenn ein Featureflag ausgewertet wird und Telemetrie aktiviert ist, ruft der Feature-Manager den Telemetrierückruf mit einem EvaluationEvent-Parameter auf. EvaluationEvent enthält die folgenden Eigenschaften:
| Tag | Beschreibung |
|---|---|
feature |
Das verwendete Featureflag. |
user |
Die Benutzer-ID, die für die Zielbestimmung verwendet wird. |
enabled |
Ob das Feature-Flag als „aktiviert“ ausgewertet wird. |
Variant |
Die zugewiesene Variante. |
VariantAssignmentReason |
Der Grund, warum die Variante zugewiesen ist. |
Nächste Schritte
Fahren Sie mit den folgenden Schnellstarts fort, um zu erfahren, wie Featureflags in Ihren Anwendungen verwendet werden.
Wenn Sie mehr über die Verwendung von Featurefiltern erfahren möchten, fahren Sie mit den folgenden Tutorials fort.